From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: On overriding make variables from the environment...
Date: Wed, 17 Oct 2018 16:29:23 +0200 [thread overview]
Message-ID: <20181017142923.GR19800@szeder.dev> (raw)
In-Reply-To: <20181016224001.GC96853@aiede.svl.corp.google.com>
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.
next prev parent reply other threads:[~2018-10-17 14:29 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-16 18:45 On overriding make variables from the environment SZEDER Gábor
2018-10-16 21:54 ` Jonathan Nieder
2018-10-16 22:33 ` SZEDER Gábor
2018-10-16 22:40 ` Jonathan Nieder
2018-10-17 14:29 ` SZEDER Gábor [this message]
2018-10-18 10:01 ` Johannes Schindelin
2018-10-18 12:49 ` Junio C Hamano
2018-12-20 16:24 ` [PATCH 0/5] travis-ci: build with the right compiler SZEDER Gábor
2018-12-20 16:24 ` [PATCH 1/5] compat/obstack: fix -Wcast-function-type warnings SZEDER Gábor
2018-12-20 23:12 ` Ævar Arnfjörð Bjarmason
2019-01-10 21:22 ` Junio C Hamano
2019-01-11 0:37 ` SZEDER Gábor
2019-01-11 18:03 ` Junio C Hamano
2019-01-11 18:51 ` SZEDER Gábor
2019-01-15 23:55 ` SZEDER Gábor
2019-01-16 1:13 ` Jonathan Nieder
2019-01-17 1:36 ` SZEDER Gábor
2019-01-16 4:16 ` Junio C Hamano
2018-12-20 16:24 ` [PATCH 2/5] .gitignore: ignore external debug symbols from GCC on macOS SZEDER Gábor
2018-12-20 16:24 ` [PATCH 3/5] travis-ci: don't be '--quiet' when running the tests SZEDER Gábor
2018-12-20 16:24 ` [PATCH 4/5] travis-ci: switch to Xcode 10.1 macOS image SZEDER Gábor
2018-12-20 16:24 ` [PATCH 5/5] travis-ci: build with the right compiler SZEDER Gábor
2019-01-03 16:01 ` Johannes Schindelin
2019-01-17 1:29 ` [PATCH v2 0/5] " SZEDER Gábor
2019-01-17 1:29 ` [PATCH v2 1/5] compat/obstack: fix -Wcast-function-type warnings SZEDER Gábor
2019-01-17 1:29 ` [PATCH v2 2/5] .gitignore: ignore external debug symbols from GCC on macOS SZEDER Gábor
2019-01-17 1:29 ` [PATCH v2 3/5] travis-ci: don't be '--quiet' when running the tests SZEDER Gábor
2019-01-17 13:28 ` Johannes Schindelin
2019-01-17 1:29 ` [PATCH v2 4/5] travis-ci: switch to Xcode 10.1 macOS image SZEDER Gábor
2019-01-17 1:29 ` [PATCH v2 5/5] travis-ci: build with the right compiler SZEDER Gábor
2019-01-17 13:44 ` Johannes Schindelin
2019-01-17 14:56 ` SZEDER Gábor
2019-01-18 8:40 ` Johannes Schindelin
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181017142923.GR19800@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).