Re: Generate Custom Compiler / Build Rules?

[Ralf Wildenhues]

* Xochitl Lunde wrote on Mon, Sep 14, 2009 at 05:12:11PM CEST:
> > Do you require GNU make or do you target portable make?
> > If the former, then you should be able to use pattern rules.
> 
> Xochitl: Our current build structure has now 4 separate directory trees 
> with makefiles.  A Linux set, an embedded set, a MacOS set, and a Windows 
> project set. I really have two goals in mind, 1.) Get the embedded tests 
> easier to maintain by not having to manually add all the rules for every 
> unit test.
> 2.) Determine if the Linux,embedded,&MacOS configure and makefiles can be 
> combined into a single set of files. As it stands right now, I have to do 
> diffs on the Linux makefiles, and then make the appropriate changes in the 
> MacOS and embedded platform makefiles.  I do this regularly whenever our 
> lead developer checks in Makefile changes. So all unit tests added to 
> Linux are added twice again, by me, to the two other platform builds.

You can, even only as an intermediate step on the way to a unified
makefile, put code common to several makefile in a fragment:
<http://www.gnu.org/software/automake/manual/html_node/Include.html>

> I'm not sure if I fully understand the question of whether I need portable 
> make.  Our embedded platform was sold to us with a "customized" Cygwin 
> distro, so nobody should ever try to build our embedded platform from any 
> shell other than this custom Cygwin shell.

And thus with any other make than GNU make.  Thus, you would be free to
use GNU make-specific constructs.  In that case I would add

  # let automake not warn about nonportable 'make' constructs
  AUTOMAKE_OPTIONS = -Wno-portability

> If the makefiles for our 3 unix-like platforms can be combined, then we 
> will be running the Linux build on a Linux PC, the embedded build in its 
> Cygwin shell, and the Mac build from Xcode or the MacOS shell.

Well, you can still use GNU make on all of them.  Your choice whether
you want to make it a prerequisite for your users or not.

> > That's due to (quoting automake/NEWS for 1.10):
> > 
> >   - `-Wportability' has finally been turned on by default for `gnu' and
> >     `gnits' strictness.  This means, automake will complain about 
> %-rules
> >     or $(GNU Make functions) unless you switch to `foreign' strictness 
> or
> >     use `-Wno-portability'.
> > 
> 
> Xochitl: So if I switch to making pattern rules, Automake 1.10 will 
> complain about these also?

Yes, because non-GNU make implementations do not support them.

> > Wrt. your posted Makefile.am file, I don't really see yet how the build
> > rules for your tests would be factorizable, it only seems to contain
> > them for one test, no?
> 
> Xochitl:  True I only pasted the rules for one test. But these rules are 
> repeated for every test with the name changed.  It's the first way I was 
> able to get it working, but now I want to make it better.

But without seeing the things the rules have in common, or differ in, we
cannot easily suggest a simplification.

> > > networktest_CXXFLAGS = -W -Wall -Werror --pedantic -O0 -g \
> > >         -DTESTCLASS=NetworkTest $(networktest_INCLUDES) \
> > >         -Wno-variadic-macros
> > 
> > Also, as another general remark, Automake makes it easy to have several
> > different build trees with different build options, e.g., one debug
> > build:
> >   ../source/configure CFLAGS=-g ...
> > 
> > and one optimized one:
> >   ../source/configure CFLAGS=-O42 ...
> > 
> > Glancing at your rules it might not be possible to separate things for
> > your code but you might at least want to think about it.
> > 
> 
> Xochitl: I don't understand how your two lines there create separate 
> builds.  Are you running configure and specifiying CFLAGS on the configure 
> command line?

Yes.
<http://www.gnu.org/software/automake/manual/html_node/Standard-Configuration-Variables.html>
<http://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html>

>  If so, this is a good thought. (If not, it is probably 
> still a good thought, but I don't understand.)  My configure already sets 
> a lot of flags, but not debug flags yet.

Cheers,
Ralf