From: Junio C Hamano <gitster@pobox.com>
To: Josh Steadmon <steadmon@google.com>
Cc: git@vger.kernel.org, calvinwan@google.com, szeder.dev@gmail.com,
phillip.wood123@gmail.com, chooglen@google.com, avarab@gmail.com,
sandals@crustytoothpaste.net
Subject: Re: Splitting common-main
Date: Fri, 14 Jul 2023 17:34:59 -0700 [thread overview]
Message-ID: <xmqqh6q6m2q4.fsf@gitster.g> (raw)
In-Reply-To: <ZLHcaFvvZh88TrLb@google.com> (Josh Steadmon's message of "Fri, 14 Jul 2023 16:38:16 -0700")
Josh Steadmon <steadmon@google.com> writes:
> Sorry, I don't think I'm understanding your proposal here properly,
> please let me know where I'm going wrong: isn't this functionally
> equivalent to my patch, just with different filenames? Now main() would
> live in main.c (vs. my common-main.c), while check_bug_if_BUG() and
> common_exit() would live in common-main.c (now a misnomer, vs. my
> common-exit.c). I'm not following how that changes anything so I'm
> pretty sure I've misunderstood.
Sorry, the old discussion has expired out of my brain, and asking
what I had in mind back then is too late.
Your common-main.c has stuff _other than_ main(), and the remaining
main() has tons of Git specific stuff. It may be one way to split,
but I did not find a reason to convince myself that it was a good
split.
What I was wondering as a straw-man alternative was to have main.c
that has only this and nothing else:
$ cat >main.c <<\EOF
#include "git-compat-util.h" /* or whatever defines git_main() */
int main(int ac, char **av)
{
return git_main(ac, av);
}
EOF
Then in common-main.c, rename main() to git_main().
I was not saying such a split would be superiour compared to how you
moved only some stuff out of common-main.c to a separate file. I
had trouble equally with your split and with the above strawman,
because I did not (and do not) quite see how one would evaluate the
result (go back to the message you are responding to for details).
> The issue I was trying to solve (whether for a unit-test framework or
> for the fuzzing engine) is that we don't have direct control over their
> main(), and so we can't rename it to avoid conflicts with our main().
Sure. And if we by default use a very thin main() that calls
git_main(), it would be very easy for them to replace that main.o
file with their own implementation of main(); as long as they
eventually call git_main(), they can borrow what we do in ours.
> I guess there may be some linker magic we could do to avoid the conflict
> and have (our) main() call (their, renamed) main()?
We can throw a main.o that has the implementation of our default
"main" function into "libgit.a".
Then, when we link our "git" program (either built-in programs that
are reachable from git.o, or standalone programs like remote-curl.o
that have their own cmd_main()), we list our object files (but we do
not have to list main.o) and tuck libgit.a at the end of the linker
command line. As the start-up runtime code needs to find symbol
"main", and the linker sees no object files listed has "main", the
linker goes in and finds main.o stored in libgit.a (which has "main"
defined) and that will end up being linked.
If on the other hand when we link somebody else's program that has
its own "main()", we list the object files that make up the program,
including the one that has their "main()", before "libgit.a" and
the linker does not bother trying to find "main" in libgit.a:main.o
so the resulting binary will use their main().
Is that what you are looking for?
next prev parent reply other threads:[~2023-07-15 0:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 23:56 [PATCH RFC v2 0/4] Add an external testing library for unit tests steadmon
2023-05-17 23:56 ` [PATCH RFC v2 1/4] common-main: split common_exit() into a new file steadmon
2023-05-18 17:17 ` Junio C Hamano
2023-07-14 23:38 ` Splitting common-main (Was: Re: [PATCH RFC v2 1/4] common-main: split common_exit() into a new file) Josh Steadmon
2023-07-15 0:34 ` Junio C Hamano [this message]
2023-08-14 13:09 ` Jeff Hostetler
2023-05-17 23:56 ` [PATCH RFC v2 2/4] unit tests: Add a project plan document steadmon
2023-05-18 13:13 ` Phillip Wood
2023-05-18 20:15 ` Glen Choo
2023-05-24 17:40 ` Josh Steadmon
2023-06-01 9:19 ` Phillip Wood
2023-05-17 23:56 ` [PATCH RFC v2 3/4] Add C TAP harness steadmon
2023-05-18 13:15 ` Phillip Wood
2023-05-18 20:50 ` Josh Steadmon
2023-05-17 23:56 ` [PATCH RFC v2 4/4] unit test: add basic example and build rules steadmon
2023-05-18 13:32 ` Phillip Wood
2023-06-09 23:25 ` [RFC PATCH v3 0/1] Add a project document for adding unit tests Josh Steadmon
2023-06-09 23:25 ` [RFC PATCH v3 1/1] unit tests: Add a project plan document Josh Steadmon
2023-06-13 22:30 ` Junio C Hamano
2023-06-30 22:18 ` Josh Steadmon
2023-06-29 19:42 ` Linus Arver
2023-06-29 20:48 ` Josh Steadmon
2023-06-30 19:31 ` Linus Arver
2023-07-06 18:24 ` Glen Choo
2023-07-06 19:02 ` Junio C Hamano
2023-07-06 22:48 ` Glen Choo
2023-06-30 21:33 ` Josh Steadmon
2023-06-29 21:21 ` Junio C Hamano
2023-06-30 0:11 ` Linus Arver
2023-06-30 14:07 ` Phillip Wood
2023-06-30 18:47 ` K Wan
2023-06-30 22:35 ` Josh Steadmon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh6q6m2q4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=calvinwan@google.com \
--cc=chooglen@google.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=steadmon@google.com \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).