On 11/11/24 11:52 PM, Jeff King wrote:
> I think the meson equivalent is that I would "meson setup build
> --native-file /path/to/my/config.mak" once, which would copy all of the
> values in to that environment. And then starting ninja from that "build"
> directory would presumably work throughout history. My config.mak does
> have some runtime logic, though (e.g., when bisecting old commits it
> relaxes the compiler options). It sounds like that would need to re-run
> meson, and not work at the ninja level.
Well, at least to change compiler options and relax them it would need
to re-run meson once.
> I'm also not clear on how to alternatively build with different
> optimization levels, or with different sanitizers. Right now that is:
>
> # normal build and test some script
> make && cd t && ./t0000-basic.sh -v -i
>
> # now with sanitizer
> make SANITIZE=address && cd t && ./t0000-basic.sh -v -i
>
> If I understand correctly, the workflow here is either to have two
> separate build directories, or to "meson configure" between the two.
> And AFAICT the tests _have_ to be run via "meson test" now, if we want
> them to find the Git built in the separate directories.
Yes, and yes. Well, kind of.
meson test t0000-basic
# supports globbing and passing args
meson test t0000* --test-args="-v -i"
GIT_BUILD_DIR=$PWD/../build ./t0000-basic.sh -v -i
are all functional. The introduction of meson doesn't change how the
tests actually work, but it does introduce an environment variable
pointing to the built git program(s) in some location other than "the
parent directory of t/ itself", and `meson test` sets that variable then
runs ./tXXXX-testname.sh itself. So you could continue to run it directly.
> [1] I think my gut feeling is that these are questions that Patrick
> should be answering if he wants to sell the project on moving away
> from make. I know we can't expect to be spoon-fed all parts of a
> transition, but I am starting from the point of view of: I am
> perfectly happy with make, why do you want me to switch?
>
> Another thing I am observing about this is that "meson" is not
> really just replacing "make". It is also replacing autoconf to some
> degree in probing various things (like gettext). But that is not
> something I (or most developers) were using at all. So it is not
> just transitioning to a different piece of software, but also
> changing the fundamental approach. Though I imagine with the right
> --native-file options, I could disable all of the probing entirely.
I would say that technically you were already probing various things. It
is simply that the Makefile performed all those probes each time you ran
`make`, e.g.
ifndef CURL_LDFLAGS
CURL_LDFLAGS = $(eval CURL_LDFLAGS := $$(shell $$(CURL_CONFIG)
--libs))$(CURL_LDFLAGS)
endif
ran curl-config --libs every time, which is very much a probe.
Other things like NEEDS_LIBICONV were not a probe, but did require the
user to know it was necessary... possibly since conditionally checking
for -liconv -lintl in a Makefile is difficult to do automatically. :)
Really, the main difference in my view is that probing is moved to an
explicit step rather than happening "under the hood" as part of
executing `make`. And that's a definite difference, since `make` is a
single step and `meson setup build && ninja -C build/` is two steps.
--
Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
