[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generate Custom Compiler / Build Rules?
From: |
Xochitl Lunde |
Subject: |
Re: Generate Custom Compiler / Build Rules? |
Date: |
Mon, 14 Sep 2009 10:12:11 -0500 |
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
>
>
>