any way to generate debug AND non-debug releases?
I would like to be able to build both debug and release builds of some libraries and apps that are using the GNU build system. It seems that there must be an easy way to specify multiple targets (one simply stripped of symbols). Can anyone point me to some docs or have suggestions on how this can be achieved with the GNU autoconf/automake /libtool/make/gcc toolchain? many thanks in advance... -allen
adding specific C flags for a SINGLE source file
Apologies if this is a FAQ: I've searched the mailing list and other standard places but not found the answer. I am working on a project which is 'stock' autoconf/automake but with one twist. There is a single routine (that lives by itself in dhrystone.C) which must ALWAYS be compiled to an object with -O3, regardless of the user specified compilation options, CFLAGS, CPPFLAGS, etc. One way to accomplish this is to put dhrystone.C into a separate subdir with its down Makefile.am. But that's ugly. Is there a better way? Here is a more detailed description. Suppose I have an executable with some simple .C source files: bin_PROGRAMS = my_prog my_prog_SOURCES = \ app.C \ app_control.C \ app_graphics.C \ dhrystone.C my_prog_DEPENDENCIES = $(LIBRSA) my_prog_CPPFLAGS = -I $(srcdir)/something $(AM_CPPFLAGS) my_prog_LDADD = $(RSA_LIBS) $(PTHREAD_LIBS) So everything is standard, except for one thing. I want to ensure that when dhrystone.C is compiled to an object file, it gets special compilation CPPFLAGS. How do I modify Makefile.am to make sure that the construction of dhrystone.o from dhrystone.C is done using special flags? (I want to always add a -O3, regardless of users preferences for CPPFLAGS). For the other files (app.C, etc) I want to follow user preferences in the standard way. Replies copied to [EMAIL PROTECTED] would be appreciated: I'm not a subscriber to this list. Cheers, Bruce
Re: adding specific C flags for a SINGLE source file
Alexandre, > bin_PROGRAMS = foo > foo_SOURCES = bar.c bar.h main.c > foo_CFLAGS = -some -flags > foo_LDADD = libfoo.a > noinst_LIBRARIES = libfoo.a > libfoo_a_SOURCES = foo.c foo.h > libfoo_a_CFLAGS = -some -other -flags Well, like all 'good answers' this one is obvious: I should have thought of it myself. Thank you! What you've written would be a nice addition to the FAQ. Thank you again! Cheers, Bruce
Re: adding specific C flags for a SINGLE source file
Alexandre, this comes *really* close to working. Problem is that in the Makefile one ends up with: $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libboincbenchmark_a_CPPFLAGS) $(CPPFLAGS) $(libboincbenchmark_a_CXXFLAGS) $(CXXFLAGS) Notice (g!!) that user's $(CXXFLAGS) is *last*. So I can't over-ride it with libboincbenchmark_a_CXXFLAGS. In other words: libboincbenchmark_a_CXXFLAGS=-O3 CXXFLAGS=-g -O2 and I end up with -O3 -g -O2. Any idea how to get around this? Cheers, Bruce On Fri, 10 Dec 2004, Alexandre Duret-Lutz wrote: > How about this proposed new entry for the FAQ? > > 26.7 Per-Object Flags Emulation > === > > One of my source files needs to be compiled with different flags. How > do I do? > >Automake supports per-program and per-library compilation flags (see > *Note Program and Library Variables:: and *Note Flag Variables > Ordering::). With this you can define compilation flags that apply to > all files compiled for a target. For instance in > > bin_PROGRAMS = foo > foo_SOURCES = foo.c foo.h bar.c bar.h main.c > foo_CFLAGS = -some -flags > > `foo-foo.o', `foo-bar.o', and `foo-main.o' will all be compiled with > `-some -flags'. (If you wonder about the names of these object files, > see *Note renamed objects::.) Note that `foo_CFLAGS' gives the flags > to use when compiling all the C sources of the _program_ `foo', it has > nothing to do with `foo.c' or `foo-foo.o' specifically. > >What if `foo.c' needs to be compiled into `foo.o' using some > specific flags, that none of the other files require? Obviously > per-program flags are not directly applicable here. Something like > per-object flags are expected, i.e., flags that would be used only when > creating `foo-foo.o'. Automake does not support that, however this is > easy to simulate using a library that contains only that object, and > compiling this library with per-library flags. > > bin_PROGRAMS = foo > foo_SOURCES = bar.c bar.h main.c > foo_CFLAGS = -some -flags > foo_LDADD = libfoo.a > noinst_LIBRARIES = libfoo.a > libfoo_a_SOURCES = foo.c foo.h > libfoo_a_CFLAGS = -some -other -flags > >Here `foo-bar.o' and `foo-main.o' will all be compiled with `-some > -flags', while `libfoo_a-foo.o' will be compiled using `-some -other > -flags'. Eventually, all three objects will be linked to form `foo'. > >This trick can also be achieved using Libtool convenience libraries, > i.e., `noinst_LTLIBRARIES = libfoo.la' (*note Libtool Convenience > Libraries::). > >Another tempting idea to implement per-object flags is to override > the compile rules `automake' would output for these files. Automake > will not define a rule for a target you have defined, so you could > think about defining the `foo-foo.o: foo.c' rule yourself. We > recommend against this, because this is error prone. For instance if > you add such a rule to the first example, it will break the day you > decide to remove `foo_CFLAGS' (because `foo.c' will then be compiled as > `foo.o' instead of `foo-foo.o', see *Note renamed objects::). Also in > order to support dependency tracking, the two `.o'/`.obj' extensions, > and all the other flags variables involved in a compilation, you will > end up modifying a copy of the rule previously output by `automake' for > this file. If a new release of Automake generates a different rule, > your copy will need to be updated by hand. > > -- > Alexandre Duret-Lutz > >
Circular dependencies and test programs
Hi, I have two libraries liba and libb. I would like liba to call a function in libb but libb is linked with liba. So I have a circular dependency. Normally this is not a problem because the linker doesn't try to resolve dependencies when linking libraries. But here's the problem: liba uses libtool / automake and builds a number of test programs not just by configure but by liba's test suite and the linker *does* try to resolve depenencies in that case. Meaning, if I try to build an executable with liba it says it needs libb but libb needs liba. So what do I do? Is there a way to tell configure "don't build executables"? Mike
Forcing an AC_CHECK to fail
Hey, I have a package that uses AC and checks for a lib but the package also has it's own implementation of that lib. I have the said lib installed on the system but I want autoconf to fail that check and used the one provided in the package. So is there a way to tell a specific check to fail? Mike
Re: Circular dependencies and test programs
Nuts. On 10/20/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > My best advice is to change the design of your libraries to avoid the > circular dependencies.
Re: Forcing an AC_CHECK to fail
On 10/20/07, Andreas Schwab <[EMAIL PROTECTED]> wrote: > > So is there a way to tell a specific check to fail? > > You can preset the cache variable before running configure. Excellent! So how to do I preset a cache variable before running configure? Mike
Re: Forcing an AC_CHECK to fail
On 10/20/07, Andreas Schwab <[EMAIL PROTECTED]> wrote: > "Michael B Allen" <[EMAIL PROTECTED]> writes: > > > So how to do I preset a cache variable before running configure? > > You can put it in the environment, or use config.site. See > (autoconf)Site Defaults. Hey Andreas, Ok. I see the docs you're talking about. Still not crystal clear what exactly I would put in the site config (AC_CACHE_VALUE I suppose). But it doesn't matter. The test in question is custom so I just sabotaged it to fail. Not an elegant solution but it works. Thanks, Mike
Re: Circular dependencies and test programs
On 10/20/07, Ben Pfaff <[EMAIL PROTECTED]> wrote: > "Michael B Allen" <[EMAIL PROTECTED]> writes: > > > But here's the problem: liba uses libtool / automake and builds a > > number of test programs not just by configure but by liba's test suite > > and the linker *does* try to resolve depenencies in that case. > > Meaning, if I try to build an executable with liba it says it needs > > libb but libb needs liba. > > > > So what do I do? > > > > Is there a way to tell configure "don't build executables"? > > If the test programs are listed on check_PROGRAMS, instead of on > some other target, then they will be built only for "make check", > not for "make all" or "make install". Hi Ben, Well that's interesting because indeed they are list on check_PROGRAMS. However, I have decided that Bob's solution is the right thing to do. It so happens that the specific code from libb needed by liba does not need liba. So by breaking up libb into a few smaller libraries I can eliminate the circular dependency and greatly reduce the number of libraries I need to link liba with. Thanks, Mike PS: I like your Linux Thinkpad page on the T30. It was very helpful.
