Re: automake distclean bug?
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob I am working to get the package I support to support the 'distcheck' Bob target. The distcheck target fails with: Bob ERROR: files left in build directory after distclean: Bob ./GraphicsMagick-1.1-20031209.tar.gz Bob Unlike the many other problems that I have already had to solve, this Bob one looks like the result of an Automake bug. How can I reproduce this? Bob Is it possible that Automake 1.7.9 does not remove its Bob distribution file via the 'distclean' target? distclean is not expected to clean tarballs, but distcheck will do it at the right time. -- Alexandre Duret-Lutz
Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?
Hi all I have a problem converting an old code base to GNU Automake, in that the developers are used to spicing up their GNU Makefiles with GNU Make conditionals, that are evaluated when make is run, in order to have some shortcut options for setting CFLAGS. They use make -DCHECK=1 to enable adding of special debuggin flags, for example, and make -DPROF=1 to add another set of flags to enable a build fro profiling. Is there a (better) way to do that using GNU Automake? I'be been browsing the archives for a while but couldn't find anything. cheers, dalibor topic
We still have places left.
Hi, We still have spaces left on our worldwide training seminars for 2004. Reply to this email for our information pack. Robert Seviour Sales Training Specifically for Engineers Tel: +44 (0)1481 720 294 Fax: +44 (0)1481 720 317 email: [EMAIL PROTECTED] PS Remember to ask for your discount If sales training is not an issue for your company please reply to this email putting "Delete" in the subject box and we will remove you from our list. Sorry for the inconvenience.
Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?
Hi Bob, thanks for the quick reply. Bob Friesenhahn wrote: You can use Automake conditionals. These are configure-time conditionals rather than make-time conditionals. You could add --with-check and --with-prof options to your configure script which enables these conditionals. Done. But shouldn't it be called --enable instead of --with? I thought --with was for external packages, and --enable was for features. If your package preserves the capability to build outside of the source tree, then your users can simply maintain seperate builds with the desired options enabled. Yeah, but the problem is that it makes some things, like doing a quick debugging or profiling build, be a little more trouble than before. Since you need to either keep the separate build around (and you may not need it all the time), and remeber to reconfigure when a part of the build machinery has changed, or you have to re-run configure each time, which is a bit of a waste of time, if all you want to have is a some CFLAGS mixing. cheers, dalibor topic
Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?
You can use Automake conditionals. These are configure-time conditionals rather than make-time conditionals. You could add --with-check and --with-prof options to your configure script which enables these conditionals. If your package preserves the capability to build outside of the source tree, then your users can simply maintain seperate builds with the desired options enabled. Bob On Wed, 10 Dec 2003, Dalibor Topic wrote: Hi all I have a problem converting an old code base to GNU Automake, in that the developers are used to spicing up their GNU Makefiles with GNU Make conditionals, that are evaluated when make is run, in order to have some shortcut options for setting CFLAGS. They use make -DCHECK=1 to enable adding of special debuggin flags, for example, and make -DPROF=1 to add another set of flags to enable a build fro profiling. Is there a (better) way to do that using GNU Automake? I'be been browsing the archives for a while but couldn't find anything. cheers, dalibor topic == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?
On Wed, 10 Dec 2003, Dalibor Topic wrote: Bob Friesenhahn wrote: You can use Automake conditionals. These are configure-time conditionals rather than make-time conditionals. You could add --with-check and --with-prof options to your configure script which enables these conditionals. Done. But shouldn't it be called --enable instead of --with? I thought --with was for external packages, and --enable was for features. Sure, that is true in principle. Just don't tell anyone that I offered bad advice. :-) The --with-prof is actually reasonable since the compiler will use a different startup object file and may select different libraries. If your package preserves the capability to build outside of the source tree, then your users can simply maintain seperate builds with the desired options enabled. Yeah, but the problem is that it makes some things, like doing a quick debugging or profiling build, be a little more trouble than before. Since you need to either keep the separate build around (and you may not need it all the time), and remeber to reconfigure when a part of the build machinery has changed, or you have to re-run configure each time, which is a bit of a waste of time, if all you want to have is a some CFLAGS mixing. Your desire for CFLAGS mixing could just as easily result in a mixed up build with different flavors of objects. A build dictated entirely by the Makefile is the only way to ensure a consistent built. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
On Dec 9, 2003, Tom Tromey [EMAIL PROTECTED] wrote: Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes: Alexandre the *_OBJECT definitions assume the absence of shell-active Alexandre characters in filenames, which is probably a safe Alexandre assumption for Makefiles. It isn't unreasonable for a Java .class file's name to contain $. Oh, but if you look closely at the macros I posted, you'll notice that this doesn't matter all that much. As long as the automake- or hand-generated definition of ofile doesn't contain shell-active characters (and IIRC automake already takes care of turning them into underscores), you're fine. And then, if it does, we need an additional variable set by the rule preamble that sets a shell-safe version of ofile. The point here is to avoid the overhead of having to run ofile through sed to protect it at build time, when we can do it at Makefile-generation time. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer [EMAIL PROTECTED], gcc.gnu.org} CS PhD student at IC-Unicamp[EMAIL PROTECTED], gnu.org} Free Software EvangelistProfessional serial bug killer
Re: automake distclean bug?
On Wed, 10 Dec 2003, Alexandre Duret-Lutz wrote: Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob I am working to get the package I support to support the 'distcheck' Bob target. The distcheck target fails with: Bob ERROR: files left in build directory after distclean: Bob ./GraphicsMagick-1.1-20031209.tar.gz Bob Unlike the many other problems that I have already had to solve, this Bob one looks like the result of an Automake bug. How can I reproduce this? Bob Is it possible that Automake 1.7.9 does not remove its Bob distribution file via the 'distclean' target? distclean is not expected to clean tarballs, but distcheck will do it at the right time. It seems that Automake 1.7.9 does *not* always do it at the right time (therefore this problem), however, updating to Automake 1.8 clears up the problem. Yay! Thanks for the excellent work with preparing Automake 1.8. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
GNU Automake 1.8 released
We're pleased to announce the release of Automake 1.8. Automake is a tool for automatically generating `Makefile.in's suitable for use with Autoconf, compliant with the GNU Makefile standards, and portable to various make implementations. This release contains many bug fixes and improvements. The NEWS entry is appended. Thanks to all people who have reported bugs, contributed code, suggested enhancements, or answered user questions on the mailing lists. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.8.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.8.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.8.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.8.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors which are listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: 0a83fd4a2a32dc966b83ca3be86f884b automake-1.8.tar.bz2 d1001db5ab96be087817e7b7b4ba3621 automake-1.8.tar.gz Please report bugs by mail to [EMAIL PROTECTED], or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake New in 1.8: * Meta-News - The NEWS file is more verbose. * Requirements - Autoconf 2.58 or greater is required. * New features - Default source file names in the absence of a _SOURCES declaration are made by removing any target extension before appending `.c', so to make the libtool module `foo.la' from `foo.c', you only need to do this: lib_LTLIBRARIES = foo.la foo_la_LDFLAGS = -module For backward compatibility, foo_la.c will be used instead of foo.c if this file exists or is the explicit target of a rule. However -Wobsolete will warn about this deprecated naming. - AR's `cru' flags are now set in a global ARFLAGS variable instead of being hard-coded in each $(AR) invocation, so they can be substituted from configure.ac. This has been requested by people dealing with non-POSIX ar implementations. - New warning option: -Woverride. This will warn about any user target or variable definitions which override Automake definitions. - Texinfo rules back up and restore info files when makeinfo fails. - Texinfo rules now support the `html' target. Running this requires Texinfo 4.0 or greater. `html' is a new recursive target, so if your package mixes hand-crafted `Makefile.in's with Automake-generated `Makefile.in's, you should adjust the former to support (or ignore) this target so that `make html' recurses successfully. If you had a custom `html' rule in your `Makefile.am', it's better to rename it as `html-local', otherwise your rule will override Automake's new rule (you can check that by running `automake -Woverride') and that will stop the recursion to subdirectories. Last but not least, this `html' rule is declared PHONY, even when overridden. Fortunately, it appears that few packages use a non-PHONY `html' rule. - Any file which is m4_included from configure.ac will appear as a configure and Makefile.in dependency, and will be automatically distributed. - The rules for rebuilding Makefiles and Makefile.ins will now rebuild all Makefiles and all Makefile.ins at once when one of configure's dependencies has changed. This is considerably faster than previous implementations, where config.status and automake were run separately in each directory (this still happens when you change a Makefile.am locally, without touching configure.ac or friends). Doing this also solves a longstanding issue: these rebuild rules failed to work when adding new directories to the tree, forcing you to run automake manually. - For similar reasons, the rules to rebuild configure, config.status, and aclocal.m4 are now defined in all directories. Note that if you were using the CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES (formerly undocumented) variables, you should better define them in all directories. This is easily done using an AC_SUBST (make sure you prefix these dependencies with $(top_srcdir) since this variable will appear at different levels of the build tree). - aclocal will now use `m4_include' instead of copying local m4 files into aclocal.m4. (Local m4 files are those you ship with your project, other files will be copied as usual.) Because m4_included files are automatically distributed, it means for most projects there is no point in EXTRA_DISTing the list of m4 files which are used. (You can probably get rid of m4/Makefile.am if you had one.) -
