Re: [lmi] make: chaining target-specific, immediately-expanded variables

[Vadim Zeitlin]

On Sat, 2 Jul 2022 20:58:00 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 7/2/22 17:14, Vadim Zeitlin wrote:
GC> [...]
GC> >  Understanding the example above in isolation is, of course, quite
GC> > different from being able to detect problems such as this one, which is 
why
GC> > I think it's important to keep makefiles as simple as possible. The fact
GC> > that you can do everything with GNU make doesn't mean you should...
GC> 
GC> The task at hand is to specify compiler options, some of which must vary
GC> by target. What tool would be more appropriate for that than 'make'?

 Oh, I didn't mean to propose using anything other than GNU make in lmi.
FWIW it's now more clear than ever that CMake has become the de facto
standard build system for C++ projects and although I dislike it as much as
before, there is just no escaping it -- not only if you want to use any
other C++ libraries but even if you need to integrate with many C++ tools
(e.g. all clang tooling, including clang-tidy, works out of the box with
CMake projects and requires additional work for anything else). But, again,
my point wasn't to say that CMake should be used for lmi, even though, in
spite of my personal feelings, I find it hard to recommend people _not_ to
use it for any new projects.

 I rather meant that makefiles had to be written in the simplest and least
surprising way possible rather than the most elegant or shortest one. In
this particular case I don't understand the problem at hand in enough
details, but a common solution to this kind of things is to define
different variables per target, e.g. product_file_optimization_flag,
something_else_optimization_flag etc, and then use these variables as
$($(target)_optimization_flag). This is perhaps less elegant than reusing
just a single variable but should be more robust.

 Of course, I could be missing some subtlety that would prevent this from
working here. I do admit that I try to look at lmi makefiles as little as
possible, but if you think it could be useful for me to do it, I could try
to propose an actual, working patch rather than a vague idea of one.

 Please let me know if I should,
VZ

pgp26Rn97JOsc.pgp
Description: PGP signature