git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: On overriding make variables from the environment...

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Oct 18, 2018, 10:01 UTC
Message-ID
<nycvar.QRO.7.76.6.1810181159200.4546@tvgsbejvaqbjf.bet>
In-Reply-To
<20181017142923.GR19800@szeder.dev>
Hi Gábor,
On Wed, 17 Oct 2018, SZEDER Gábor wrote:
Show 65 quoted lines
> On Tue, Oct 16, 2018 at 03:40:01PM -0700, Jonathan Nieder wrote:
> > SZEDER Gábor wrote:
> > > On Tue, Oct 16, 2018 at 02:54:56PM -0700, Jonathan Nieder wrote:
> > >> SZEDER Gábor wrote:
> > 
> > >>> Our Makefile has lines like these:
> > >>>
> > >>>   CFLAGS = -g -O2 -Wall
> > >>>   CC = cc
> > >>>   AR = ar
> > >>>   SPATCH = spatch
> > [...]
> > >>> I'm not sure what to do.  I'm fine with updating our 'ci/' scripts to
> > >>> explicitly respect CC in the environment (either by running 'make
> > >>> CC=$CC' or by writing $CC into 'config.mak').  Or I could update our
> > >>> Makefile to use '?=' for specific variables, but:
> > >>
> > >> That's a good question.  I don't have a strong opinion myself, so I
> > >> tend to trust larger projects like Linux to have thought this through
> > >> more, and they use 'CC = cc' as well.
> > >
> > > I don't think Linux is a good example to follow in this case, see e.g.
> > > 6d62c983f7 (Makefile: Change the default compiler from "gcc" to "cc",
> > > 2011-12-20) (in short: Git is supposed to be buildable with compilers
> > > other than GCC as well, while Linux not really, so they can hardcode
> > > 'CC = gcc').
> > 
> > Nowadays Linux builds with clang as well.  People also have other
> > reasons to override the CC setting (cross-compiling, etc) and to
> > override other settings like CFLAGS.
> > 
> > > Also, the projects I have on hand usually have 'CC = gcc' hardcoded in
> > > their Makefiles, too, but those Makefiles were generated by their
> > > ./configure script (which in turn by ./autogen.sh...), and those tend
> > > to write CC from the environment into the generated Makefiles.
> > 
> > Yes, I think that's what makes travis's setup normally work.  It makes
> > sense to me since ./configure is expected to have more implicit or
> > automatic behavior.  For "make", I kind of like that it doesn't depend
> > on environment variables that I am not thinking about when debugging a
> > reported build problem.
> > 
> > When building Git without autoconf, the corresponding place for
> > settings is config.mak.  Would it make sense for the ci scripts to
> > write a config.mak file?
> 
> A first I though it doesn't, but it turns out it acually does.
> 
> 'ci/run-build-and-tests.sh' basically runs:
> 
>   make
>   make test
> 
> I naively put a 'CC=$CC' argument at the end of the first command,
> thinking it should Just Work...  but then that second 'make test' got
> all clever on me, said "* new build flags", and then proceeded to
> rebuild everything with the default 'cc'.  (With the additional
> complication, that on Travis CI we actually run 'make --quiet test',
> which rebuilds everything, well, quietly...  so the rebuild itself is
> not even visible in the build logs.)
> 
> So, then it's either 'config.mak', or passing a 'CC=$CC' argument to
> _all_ make commands, including those that are not supposed to build
> anything, but only run the tests.  I find the latter aesthetically not
> particularly pleasing.
How about using `MAKEFLAGS`? I ran a quick test:
	MAKEFLAGS='CC=blub' make -C .. git.o
	make: Entering directory '/usr/src/git/wip'
	    * new build flags
	    CC git.o
	/bin/sh: blub: command not found
In other words, you could add something like this to the ci/ script:
	MAKEFLAGS="${MAKEFLAGS:+$MAKEFLAGS }CC=$CC"
	export MAKEFLAGS

Ciao, Dscho

Previous: SZEDER GáborNext: Junio C Hamano
Message 6 of 33 in “On overriding make variables from the environment...”
  1. SZEDER GáborOct 16, 2018
  2. Jonathan NiederOct 16, 2018
  3. SZEDER GáborOct 16, 2018
  4. Jonathan NiederOct 16, 2018
  5. SZEDER GáborOct 17, 2018
  6. Johannes SchindelinOct 18, 2018
  7. Junio C HamanoOct 18, 2018
  8. 0/5 travis-ci: build with the right compilerSZEDER Gábor, Dec 20, 2018
  9. 1/5 compat/obstack: fix -Wcast-function-type warningsSZEDER Gábor, Dec 20, 2018
  10. Ævar Arnfjörð BjarmasonDec 20, 2018
  11. Junio C HamanoJan 10, 2019
  12. SZEDER GáborJan 11, 2019
  13. Junio C HamanoJan 11, 2019
  14. SZEDER GáborJan 11, 2019
  15. SZEDER GáborJan 15, 2019
  16. Jonathan NiederJan 16, 2019
  17. SZEDER GáborJan 17, 2019
  18. Junio C HamanoJan 16, 2019
  19. 2/5 .gitignore: ignore external debug symbols from GCC on macOSSZEDER Gábor, Dec 20, 2018
  20. 3/5 travis-ci: don't be '--quiet' when running the testsSZEDER Gábor, Dec 20, 2018
  21. 5/5 travis-ci: build with the right compilerSZEDER Gábor, Dec 20, 2018
  22. Johannes SchindelinJan 3, 2019
  23. 4/5 travis-ci: switch to Xcode 10.1 macOS imageSZEDER Gábor, Dec 20, 2018
  24. 0/5 travis-ci: build with the right compilerSZEDER Gábor, Jan 17, 2019
  25. 1/5 compat/obstack: fix -Wcast-function-type warningsSZEDER Gábor, Jan 17, 2019
  26. 2/5 .gitignore: ignore external debug symbols from GCC on macOSSZEDER Gábor, Jan 17, 2019
  27. 3/5 travis-ci: don't be '--quiet' when running the testsSZEDER Gábor, Jan 17, 2019
  28. Johannes SchindelinJan 17, 2019
  29. 4/5 travis-ci: switch to Xcode 10.1 macOS imageSZEDER Gábor, Jan 17, 2019
  30. 5/5 travis-ci: build with the right compilerSZEDER Gábor, Jan 17, 2019
  31. Johannes SchindelinJan 17, 2019
  32. SZEDER GáborJan 17, 2019
  33. Johannes SchindelinJan 18, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.