automake-bounces+xochitl_lunde=tripplite....@gnu.org 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 > > >
