Re: Generate Custom Compiler / Build Rules?

[Xochitl Lunde]

address@hidden wrote on 09/13/2009 
12:09:31 PM:

> Hello Xochitl,
> 
> * Xochitl Lunde wrote on Thu, Sep 10, 2009 at 09:27:31PM CEST:
> > I have an embedded platform for which I override all the make rules by 

> > writing the make rules by hand in Makefile.am.  I have tested this 
out, 
> > and it works great, but because we have many unit tests, I have to 
copy 
> > and paste the rules over and over and over as we add unit tests. 
> 
> Ouch.  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.

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.  However, the people who gave 
us the Cygwin didn't ship with a fully functional automake (aclocal-1.10 
folder is missing), so I have gone online and downloaded automake 1.9.6 
and installed to Cygwin. (Automake 1.10 didn't work because of that 
-Wportability thing.)

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.

Thank you for mentioning the term 'pattern rule'.  Before I was at a loss 
on what to search for to find related information.

> > This 
> > is just getting unweildy if I ever have to adjust the rule a little 
bit. I 
> > want to figure out how I can have automake create the correct rules 
for my 
> > embedded platform for each item in bin_PROGRAMS. 
> 
> OK.
> 
> > Also, the 3rd party libraries which I am linking have circular 
> > dependencies, and so I end up needing to use the --start-group and 
> > --end-group flags in the linker command line.  I haven't been 
successful 
> > trying to figure out which libraries to list in what order, although I 
am 
> > getting closer.
> 
> Adding --preserve-dup-deps to AM_LIBTOOLFLAGS or <target>_LIBTOOLFLAGS
> can help.
> 
> > Automake complains if I put --start-group in 
> > networktest_LDFLAGS or in networktest_LDADD.  Is it not possible to 
use 
> > this flag in Makefile.am without defining custom rules?
> 
> It ought to work for automake if you use
> -Wl,--start-group,-lfoo,-lbar,--end-group but then libtool might reorder
> this wrongly for you.  This is a problematic area alright.
> 

Xochitl: The problem is that it tells me that --start-group and 
--end-group belong in LDFLAGS, but the libraries belong in LIBS or LDADD. 
So I can't see how to put the libraries in between the two flags.  It's OK 
though, I might be close to figuring out these circular dependencies, and 
your preserve-dup-deps should help.

> > And the very last thing, Automake 1.10 complains about the "$(shell 
pwd)" 
> > in my 'debugfile' definition in Makefile.am, but Automake 1.9.6 
handles it 
> > just fine.  Which one is confused or how should I write this?
> 
> 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?

> 
> 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.

> 
> > # From Makefile.appbuild.ns9215, additional code needs to be compiled.
> > nodist_networktest_SOURCES= 
$(ac_netos_dir)/src/bsp/common/appconf_api.c
> > 
> > networktest_INCLUDES = -include $(top_srcdir)/..
> /common/tests/network/networktest.h
> 
> I don't think foo_INCLUDES works, you should use foo_CPPFLAGS instead.

Xochitl: It actually does work for me, but thanks I will correct this when 
I get the chance.

> 
> > 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?  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.

> Hope that helps.

Xochitl: Yes! Very many thanks to you!

> 
> Cheers,
> Ralf
> 
> 
>