Automake security problem
I am using CVS automake. After doing a 'make dist', I find that all the files in my source directories are marked world read/write. This makes it easier for others to add trojan horses to the code I write. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Pass additional options to libtool?
On 6 Apr 2000, Alexandre Oliva wrote: On Apr 6, 2000, Bob Friesenhahn [EMAIL PROTECTED] wrote: What is the approved mechanism to selectively pass additional options to libtool from Automake? I don't think we have one so far. But this should work: LIBTOOL = @LIBTOOL@ --silent This will work, however, it will be applied in all cases, not just for the install mode. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: How to install config.h
On Mon, 30 Oct 2000, Ossama Othman wrote: On Tue, Oct 31, 2000 at 01:40:30AM +0100, Assar Westerlund wrote: I would agree with Gary here that the symptom is installing the config.h (or whatever it's called). The problem is that the interface exported from the library should not depend on the parameters found out by configure. Yes! I certainly do agree with you on this point. However, sometimes this can't be avoided in the case of inlined functions (e.g. C++). It Besides inlined functions, it is not uncommon to see data structures changing in size, either because there are additional members, or the size of members has changed. If we should not be installing config.h files, then it would be beneficial for Automake (or Autoconf) to support an automated way to provide the benefits of config.h, but in a better form. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: More an autopackage
On Thu, 18 Jan 2001, Geoffrey Wossum wrote: Anyway, here's some of my thoughts about it: 1) written in Python Wouldn't Perl5 be a more widely acceptable choice? Considerably so? (Indeed, isn't automake already in Perl? Why choose something different? Especially when that something is considerably less widely installed?) I originally considered Perl5, basically because automake is in Perl Aren't we supposed to use GNU guile for all FSF-supported script-based tools? In fact, isn't Automake itself intended to be eventually re-written in guile? If you don't like the current languages that guile supports, you can always write a Python implementation that runs under guile (as they did for Tcl) and implement using Python syntax. Ducking and running ... Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
libtool erroneously assumes -L/path to libtool library
Using CVS libtool, it appears that when a package installs several libraries, with some libraries depending on other libraries, the install step for a library which depends on another library fails. The failure is due to not supplying the required -L option to find the already installed library. The following is an example of the problem: /bin/sh ../../libtool --silent --mode=install /usr/bin/install -c libMagick++.la /build/buildd/imagemagick-5.4.6/debian/imagemagick/usr/lib/libMagick++.la libtool: install: warning: relinking `libMagick++.la' g++ -shared -nostdlib /usr/lib/crti.o /usr/lib/gcc-lib/m68k-linux/2.95.4/crtbeginS.o .libs/Blob.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o .libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o .libs/TypeMetric.o -L/usr/X11R6/lib -L/usr/lib -lMagick -L/usr/lib/gcc-lib/m68k-linux/2.95.4 -lstdc++ -lm -lc -lgcc -lc /usr/lib/gcc-lib/m68k-linux/2.95.4/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libMagick++.so.5 -o .libs/libMagick++.so.5.0.46 -L/usr/X11R6/lib -L/usr/lib -lMagick -L/usr/lib/gcc-lib/m68k-linux/2.95.4 -lstdc++ -lm -lc -lgcc -lc /usr/bin/ld: cannot find -lMagick collect2: ld returned 1 exit status libtool: install: error: relink `libMagick++.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/lib' Libtool should know where libMagick is installed since it has access to the libMagick.la file, however, it failed to supply the required -L option to the linker so that the installed library is found. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 1,000 year backward compatability of tools
On Wed, 19 Feb 2003, John W. Eaton wrote: But now? Do we really have to worry about these old systems? If people enjoy the vintage hardware, then is it that bad if they can only use vintage software on it as well? To install modern software on one of these vintage systems would be like putting chrome mag wheels on a Rolls Royce. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Non-recursive make intermediate objects
Using Automake 1.7.9, I am attempting to create a single Makefile.am which is capable of building all of the libraries used by the project. The source files to the project are located in subdirectories, and the output libraries should also be located in subdirectories. The objective is to replace an existing recursive build. Using a rule like: noinst_LIBRARIES = libs/somedir/libfoo.a libs_somedir_libfoo_a_SOURCES=foo.cc and then inpecting the output of 'make -n' (and the generated Makefile), I see evidence that the build will put all .Po files in a .deps subdirectory under the Makefile.am, and all the .o files in the same directory as Makefile.am. This approach seems quite wrong to me since it is quite possible that libraries and applications may use similarly named source files. Intermediate files should be placed either under the directory where the library is placed, or in the directory where the source files live. An even better solution would allow the user to specify where intermediate files are placed on a per-library and per application basis. Is there a way to convince Automake to behave more usefully? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make intermediate objects
On Thu, 20 Nov 2003, Robert Collins wrote: subdir_objects in your automake options. Problem is, there is a design headache that makes recursive clean fail with this approach - I forget the bug #, but it's on my todo, waay down there :p. Ahhh, subdir-objects. Since this is so important to non-recursive makes, it would be useful if it was referenced in the An Alternative Approach to Subdirectories section of the documentation. Please move the clean bug up in the priority level. Automake has a non-recursive user now. :-) I suspect/believe that libtool will have some problems as well. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
AM_CPPFLAGS vs INCLUDES
The Automake documentation claims that 'INCLUDES' is the equivalent of 'AM_CPPFLAGS'. However, I find that this is not the case at all. If AM_CPPFLAGS is used, then any per-target CPPFLAGS option completely overrides it. However, if INCLUDES is used, then per-target CPPFLAGS options augment the value provided via INCLUDES. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
subdir-objects object file obfustication
I have a non-recursive make working successfully using Automake 1.7.9 and the 'subdir-objects' option. Before the 'subdir-objects' option was supplied, it appeared that objects and dependency files were written to the current directory using their normal base file names (with directory part stripped). After the 'subdir-objects' option is supplied, the objects and dependency files are placed in the same directory as the source files, but the object/depenendency file names are modified so that they are prefixed with the Automake target name. For example foo/bar/splat/file.c results in foo/bar/splat/foo_bar_none_file.o Is this the expected behaviour, or is the sense of the 'subdir-objects' logic reversed? It makes more sense that if 'subdir-objects' is not supplied that intermediate files use the protective name prefixing whereas if 'subdir-objects' is supplied, the name prefixing is unneeded and undesireable. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make intermediate objects
On Sat, 22 Nov 2003, Robert Collins wrote: Please move the clean bug up in the priority level. Automake has a non-recursive user now. :-) We've had them for ages - I've been using it for 2 years now in progressive increasing sizes I keep meaning to get back to my transforming include patch (http://sources.redhat.com/ml/automake/2001-08/msg00112.html) to make authoring them less unpleasant. PR 373 is the bug I was referring to on clean - it's a general race condition. http://mail.gnu.org/archive/html/automake/2003-07/msg00064.html is a relevant email in this list archives. So this bug is only present if SUBDIRS is used to cause the Makefile to also have a recursive aspect. I suspect/believe that libtool will have some problems as well. libtool has worked fine for me, with non recursive make for 2 years now. Not to say there are not issues to find :}. Right. I have not noticed a libtool problem when using the recursive make. I am not using SUBDIRS so the only issue I have noticed thus far is odd-naming of intermediate objects. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: AM_CPPFLAGS vs INCLUDES
On Tue, 25 Nov 2003, Alexandre Duret-Lutz wrote: Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob The Automake documentation claims that 'INCLUDES' is the Bob equivalent of 'AM_CPPFLAGS'. However, I find that this is Bob not the case at all. If AM_CPPFLAGS is used, then any Bob per-target CPPFLAGS option completely overrides it. Thanks for pointing this out. I'm checking this in. My point was not entirely that the documentation was wrong. It is an extremely useful capability to be able to define a common base set of CPPFLAGS and then use per-target CPPFLAGS to extend these (equivalent to +=). Otherwise the Makefile.am has to be very messy and large, since as soon as you add one per-target CPPFLAGS, you then need to start passing all CPPFLAGS via individual per-target CPPFLAGS The current operation of INCLUDES in conjunction with per-target CPPFLAGS is effectively INCLUDES=$(CPPFLAGS) TARGET_INCLUDES=$(INCLUDES) $(TARGET_CPPFLAGS) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Non-recursive make maintenance issue
The most non-productive aspect I have found when using Automake to build projects in subdirectories is that it is very tedious to translate '/'s (and other special characters) in paths and filenames to '_' when defining target parameters. The situation becomes worse with non-recursive approaches than the recursive approach. The carrying forward of this Automake approach to target parameter names makes the Makefile much more difficult to maintain than it should be since both non-translated and translated paths must be maintained in the Makefile and there is ambiguity. Perhaps it is time for Automake to re-assess this design decision. If the capability is added to perform automatic path/filename translation, then Automake can do the transformations for the user so that the user never needs to deal with translated paths. The path translation should know how to expand macros so that target parameter names can be built from macro components. In other words, dealing with junk like apps_build_postgres_src_build_postgres_SOURCES is very tiring and failure prone. Is there a reason why it can't simply be apps/build-postgres/src/build-postgres_SOURCES ? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Adding --tag=CXX
In a build environment I am creating using Automake 1.7.9 CVS libtool, GCC (gcc g++) are used as the normal compiler. However, sometimes developers want to substitute 'insure' as the compiler in order to do memory leak checking. My understanding is that 'insure' runs the tested gcc or g++ under the covers so from libtool's perspective, there should be no change. Unfortunately, it is not possible to simply substitute one compiler name for another since libtool uses the compiler name to determine the tag. It turns out that adding --tag=CC for C, and --tag=CXX for C++, is sufficient to cause libtool to accept the new compiler name using an existing tagged configuration. Does anyone have some experience they can share with accomplishing this in an Automake-based environment? It would be useful if Automake would detect libtool 1.5 or greater and automatically supply the correct --tag option at the correct points. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Adding --tag=CXX
As an addendum to this topic, it used to be easy to override how Automake uses libtool, but this is no longer the case. For example, I could insert this in Makefile.am to override the default: LTCOMPILE = $(LIBTOOL) --mode=compile --tag=CC $(CC) $(DEFS) \ $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ $(AM_CFLAGS) $(CFLAGS) unfortunately, current Automake inserts oodles of target-specific rules that hard-code how libtool is executed on a per-target basis so that its operation can not be overridden in the Makefile.am on a per-language basis. Only the simple pattern rules use LTCOMPILE and friends. The libtool --tag option must appear before $(CC). I do not see a trivial way to add the --tag option to Makefile.in. Bob On Tue, 25 Nov 2003, Bob Friesenhahn wrote: In a build environment I am creating using Automake 1.7.9 CVS libtool, GCC (gcc g++) are used as the normal compiler. However, sometimes developers want to substitute 'insure' as the compiler in order to do memory leak checking. My understanding is that 'insure' runs the tested gcc or g++ under the covers so from libtool's perspective, there should be no change. Unfortunately, it is not possible to simply substitute one compiler name for another since libtool uses the compiler name to determine the tag. It turns out that adding --tag=CC for C, and --tag=CXX for C++, is sufficient to cause libtool to accept the new compiler name using an existing tagged configuration. Does anyone have some experience they can share with accomplishing this in an Automake-based environment? It would be useful if Automake would detect libtool 1.5 or greater and automatically supply the correct --tag option at the correct points. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 'ccache gcc' as compiler with libtool
On a related note, I learned yesterday that I can bend Automake to my will by adding this to Makefile.am: LIBTOOL = @LIBTOOL@ $(LIBTOOL_TAG) and then externally pass a tag option like make CXX='foo' LIBTOOL_TAG='--tag=CXX' I believe that Automake would be more robust with Libtool 1.5 and later if it automatically provided the --tag= option to libtool. Many leak-check tools (and perhaps other kinds of tools) are designed to replace the normal compiler. Usually they invoke the same compiler that was used by configure. Since this causes a compiler name change, the libtool does not work without a --tag=lang option. Bob On Wed, 26 Nov 2003, Vincent Caron wrote: Hello, I'm running automake 1.7.9 as packaged in Sid, and having trouble using 'cache gcc' as compiler. I get this error : /bin/sh ../libtool --mode=link ccache g++ -Wall [...] libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' As far as I could see, libtool extract the compiler name from the first non-option argument, and stop parsing from here. So it identifies the compiler (his internal var is base_compile) as 'ccache', and fails. Since Libtool is not 'wrong' and I don't see good ways to change its command line parsing without breaking it, I chose to quote the compiler name in automake invocations of libtool. I hope this 3-liner patch is useful. == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 'ccache gcc' as compiler with libtool
On Wed, 26 Nov 2003, Earnie Boyd wrote: So, you need to file name='~/bin/cg++' status=untested #! /bin/sh ccache g++ $@ /file Make sure ~/bin is in PATH and use cg++ to execute. This approach does not work with libtool 1.5 and later unless this script is specified as CXX for configure. Sometimes configuring using the alternate compiler driver is not desireable since it may be doing exotic things like memory or CPU profiling during the configure run. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make maintenance issue
On Thu, 27 Nov 2003, Jirka Hanika wrote: In other words, dealing with junk like apps_build_postgres_src_build_postgres_SOURCES is very tiring and failure prone. Is there a reason why it can't simply be apps/build-postgres/src/build-postgres_SOURCES ? Speaking as a random user, this would only be a win (to me) if the translation could also be significantly messified to keep your target above distinct from, say, apps/build/postgres-src-build/postgres_SOURCES or if this kind of conflict would be at the very least well diagnosed and warned about. Right. Since there is only one translation available, it doesn't matter if the translation was done manually or automatically. Automake's naming scheme requires the user's directory and file names to be non-ambiguous after translation. But people have to interface automake-generated code with user stuff, and this is usually done through variables. I expect a big problem here. It is not a problem as long as Automake provides sufficient automatic translation capabilities. There just needs to be a standard way to create definitions and refer to existing definitions, including those that Automake generates for its use. In order to avoid confusion, Automake could adopt a GNU-make function style syntax which indicates where translations are required. For example: $(xlate foo/bar++)_SOURCES would be automatically translated by Automake to foo_bar___SOURCES and substitution of existing Makefile defines (but not defines based on autoconf substituted values) should also work so the following should produce the same result: FOO_BAR=foo/bar++ $(xlate $(FOO_BAR))_SOURCES This would be extremely useful since it would allow a package's directory organization to be re-arranged without excruciating pain. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 'ccache gcc' as compiler with libtool
On Fri, 28 Nov 2003, Gary V. Vaughan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Duret-Lutz wrote: | How can automake determine whether the version of libtool used in | a package supports --tag ? test -n `libtool --help | grep -- --tag=TAG` This doesn't seem like good advice given that due to recent libtool changes, both Automake's Makefiles and libtool itself will be generated at the same time (at the end of the configure run). :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make maintenance issue
On Sun, 30 Nov 2003, Alexandre Duret-Lutz wrote: Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: [...] Bob In other words, dealing with junk like Bob apps_build_postgres_src_build_postgres_SOURCES Bob is very tiring and failure prone. Is there a reason why it can't Bob simply be Bob apps/build-postgres/src/build-postgres_SOURCES ? Yes. Makefile variable names can only consist of alphanumerics, underscores, and periods. Use of any other character is not standard, and likely not portable. `/' is definitely not portable; for instance OSF1 Make has a special operator $(MACRO/left/right) that would conflict with such variable names. Makefile.am is *not* a Makefile. It is input to a tool which processes it into a Makefile. I see no reason why Makefile.am can not incorporate features and syntax which diverge from 'make' since the tool (Automake) transforms this into strict make syntax. If a Makefile.am identifier violates 'make' syntax, then it can simply be transformed into an identifier which is compatible with 'make' syntax. With a little care, emacs can still edit Makefile.am in Makefile mode. A legacy implementation simplification is causing non-recursive Makefiles to be tremendously more difficult to develop and maintain than need be. Recursive makefiles only occassionally need name-munging to comply with Automake syntax (if the author chose an odd name for his library or program), but non-recursive makefiles need this name-munging for each and every target definition since subdirectory paths include '/'. If Automake has a reliable way to tell when an identifier must be munged, then there is no reason why it can't do this automatically while it generates the Makefile.in files. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make maintenance issue
On Tue, 2 Dec 2003, Robert Collins wrote: On Tue, 2003-12-02 at 02:10, Bob Friesenhahn wrote: Hmm, I'd prefer to do it via the include mechanism - see my crude, but effective updated proof of concept - posted here a minute ago. I like your include approach. It helps convert existing recursive builds into non-recursive builds with minimum pain. However, there are sufficient reasons to write only one Makefile (e.g. source tree is treated as read only, or personal preference) that both mechanisms should be supported. I'm not arguing against the single-big-file-method... but I am curious: how does a 'read only' source tree affect this? If there is a Makefile.am in it that you want to use without alteration, you can just SUBDIRS= x y z #not subdir DIST_SUBDIRS=x y z subdir subdir_include subdir/Makefile.am By 'read only', I mean that there is an existing source tree with no Makefile.am's (perhaps it uses some other build system) and you are not allowed to (or shouldn't) update it. Since Automake supports subdirectories, the Makefile.am doesn't need to reside in the source tree and it doesn't care if files which would normally conflict with Automake already exist in the tree. That was the case for my latest Automake expedition. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make maintenance issue
On Mon, 1 Dec 2003, Robert Collins wrote: and substitution of existing Makefile defines (but not defines based on autoconf substituted values) should also work so the following should produce the same result: FOO_BAR=foo/bar++ $(xlate $(FOO_BAR))_SOURCES This would be extremely useful since it would allow a package's directory organization to be re-arranged without excruciating pain. Hmm, I'd prefer to do it via the include mechanism - see my crude, but effective updated proof of concept - posted here a minute ago. I like your include approach. It helps convert existing recursive builds into non-recursive builds with minimum pain. However, there are sufficient reasons to write only one Makefile (e.g. source tree is treated as read only, or personal preference) that both mechanisms should be supported. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Status of non-recursive automake
On Wed, 3 Dec 2003, John Darrington wrote: Is non-recursive currently supported in automake or is it still in development/ideas stage? If it's already working, what version do I need, and what documentation exists? Based on my recent experience, non-recursive builds are working very well in the current automake release. Use 'subdir-objects' in AUTOMAKE_OPTIONS if you want the objects to be placed at the same relative location as the source files. An issue with the 'clean' target has been reported for the case where the makefile is also recursive (SUBDIRS is used). Objects get unnecessary funny naming in the case where TARGET_CPPFLAGS is used but this doesn't seem to break anything. Since the '/' in target definitions are not make syntax compatible, all the '/'s in target definitions need to be manually smashed to '_'. This is very tedious and error prone, and is something that Automake should fix. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Desired feature
It would be useful if Automake supported a set of options (e.g. LDFLAGS) which are applied only when building libraries or when building programs. It is excessively painful to have to add per-target _LDFLAGS options. Perhaps there should be both 'LT' and non-'LT' macro versions. Certainly this can be accomplished by overriding Automake's standard LINK and COMPILE definitions, but overriding standard definitions is risky. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Status of non-recursive automake
On Thu, 4 Dec 2003, John Darrington wrote: On Wed, Dec 03, 2003 at 02:38:52PM -0600, Bob Friesenhahn wrote: Does src1/foo.c exist? Yes. Are you using Automake 1.7.9? No. I was using 1.7.6 and it seemed that atl_SOURCES=src1/foo.c works fine with this version. So presumably the underscore thing was introduced between 1.7.6 and 1.7.9 The underscore rule applies to the names to the *left* of the '=', not the right. Paths on the right are just fine. If your target library/program resides in a subdirectory, you will soon experience what I have been complaining about. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Desired feature
On Thu, 4 Dec 2003, Gary V. Vaughan wrote: Actually, now that you point it out, I would hit that problem myself, since m4 has normal _LTLIBRARIES, noinst_LTLIBRARIES and modules. I would be happy if I could do this: ~AM_LDFLAGS = everything gets these ~noinst_LTLIBRARIES_LDFLAGS = these are for convenience libs ~lib_LTLIBRARIES_LDFLAGS = these are for other libtool libs ~libm4_la_LDFLAGS = but I can override non module libs individually That is, I think target specific flags should override PRIMARY group flags, not be in addition to them. I tend to disagree with you on this point. I will agree if the system has three levels plus a way to provide overrides. For example, if the user configures like ./configure LDFLAGS=-lbar then I believe that this user-requested value should be applied to all targets. Likewise, the configure script may want to contribute some common LDFLAGS parameters. Automake should support o inheritance of standard configure flags o flags common across all targets o additional flags common to a grouping of targets o additional flags specific to just one target o a way to override common flags at any level. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: VPATH and Relative vs. Absolute pathnames
On Sun, 7 Dec 2003, John Darrington wrote: Is there any way to instruct automake to only use relative pathnames in its makefile? This way, one could actually use the VPATH feature, which is essential if you're building a project under certain CM systems. In conjunction with Autoconf, Automake already provides the ability to build from outside of the source tree. What purpose do you need to use VPATH for? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make maintenance issue
On 9 Dec 2003, Tom Tromey wrote: Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob In other words, dealing with junk like Bob apps_build_postgres_src_build_postgres_SOURCES Bob is very tiring and failure prone. Is there a reason why it can't Bob simply be Bob apps/build-postgres/src/build-postgres_SOURCES ? Yeah, that does seem easier. One problem is that you might refer to these variables elsewhere in your Makefile, and it isn't clear that automake can reliably rewrite all uses. If the user is able to define a formal synonym for the path, then this synonym can be used everywhere but in the synonym definition itself. That should ensure that automake has no difficulties and it allows the user to write a more compact Makefile.am. All automake needs is a unique way to identify the target. The initial reason for canonicalizing macro names was simply that automake was pretty dumb, and passed through its input directly to its output. Rewriting wasn't really possible. Exactly. Automake is much more powerful these days. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Help Requests
On Tue, 9 Dec 2003, David Wolfe wrote: AFAIK There's a third possibility : you could setup a dist-hook target in Makefile.am which allows you to specify completely your dist rule I suspect I'm too lazy for that. ;-) Seems like it would be more fun to take a stab at hacking automake to work with my setup. Or is the config files must be in the top-level dir rule so ingrained into the tool that this is extremely unlikely? I don't believe that the config files need to be in the top level directory. You can place those elsewhere since Autoconf Automake can be told where to find the tools. The only claim I have seen is that the top Makefile.am/Makefile.in has to be at the top of the source tree. That only makes for two files in the top directory, for a total of three once the source tree is configured. If you are exceedingly lazy, you might want to look for a new line of work. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: C programs using C++ libraries
On Tue, 9 Dec 2003, Billy Biggs wrote: I have a C program that uses a library which internally uses C++, but exposes a C API. I have a user who experiences linking problems about missing standard C++ stuff, fixed by using g++ to link. I am looking for help in understanding this and what the correct solution is. This has been discussed before on this list [1] and solutions given. I could build a dummy.cc to force C++ linking, I could use my own program_LINK, or I could do some magic with setting CCLD or similar. I have a few questions, please let me know if there is a better forum for them: 1. Why does my program need to be linked with a C++ compiler in some cases and not in others? Shared libraries should bring in their own dependencies, or libtool should find them, no? Is something broken with how the library is built? Operating system support varies regarding embedded dependency information in shared libraries, so depending on that feature is not portable. Libtool would help handle library dependencies if the problem library was linked using libtool, since then there would be a .la file associated with the library which includes the known library dependencies. Besides library dependencies, C++ code may also have different program intialization requirements (e.g. to support static construction, destruction, and exceptions) so a different startup module (the code that eventually invokes main()) may be supplied by the compiler. 2. I use libtool (but I do not understand why I use it). Is the following correct for my program_LINK command if I use libtool: program_LINK = $(LIBTOOL) --mode=link $(CXX) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) -o $@ This seems to be from an Automake generated Makefile. Are you using Automake? Passing the C++ compiler as the tool to use for linking seems reasonable. 3. Who defines CXXLD and how? I have seen this variable referenced, it looks like I should use it above (to match CCLD), but nothing seems to define it. Is it obsolete? I believe that this is a definition generated by the AC_PROG_LIBTOOL autoconf macro. If you are not including libtool with your package, then this macro won't be defined. If you are embedding libtool in your package, then you should definitely include AC_PROG_LIBTOOL in configure.ac. Thanks for your help, -Billy [1] http://mail.gnu.org/archive/html/automake/2002-11/msg00046.html == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
automake distclean bug?
I am working to get the package I support to support the 'distcheck' target. The distcheck target fails with: ERROR: files left in build directory after distclean: ./GraphicsMagick-1.1-20031209.tar.gz Unlike the many other problems that I have already had to solve, this one looks like the result of an Automake bug. Is it possible that Automake 1.7.9 does not remove its distribution file via the 'distclean' target? Bob == 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?
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: 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
Re: making convenience libraries without libtool
I believe that Automake relies on libtool to support convenience libraries. Bob On Thu, 11 Dec 2003, Marty Leisner wrote: I'm using libtool to make convenience libraries merging sublibraries... I really don't need to use libtool since I don't build shared libraries. How can I use automake to build convenience libraries -- or do I need to make a command in the makefile.am I can invoke like this: build_lib -o libtarget.a foo/libfoo.a bar/libbar.a common/libcommon.a where build lib busts up the archive foo, bar and common into a temporary directory and then build libtarget.a. marty [EMAIL PROTECTED] Don't confuse education with schooling. Milton Friedman to Yogi Berra == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
On 16 Dec 2003, Tom Tromey wrote: The problem is, automake generates an explicit rule for each compilation. Our resulting Makefile.in is nearly 9 megabytes. This is really much too large -- compare to 200K with automake 1.4. I have observed the same problem myself. It is not language dependent. At some point (perhaps when subdirectory builds were introduced) Automake diverged from using common rules, and started to insert per-target rules. It seems that a bit more smarts can be used to get close to automake 1.4 efficiency. Per-subdirectory rules and definitions can be added in order to significantly reduce the amount of redundant code, and to re-enable the capability to usefully override parts of the default Makefile.in. One idea we had for a fix is to introduce a new gnu-make option that would allow automake to generate code relying on GNU make. Then we could replace all those rules with a single %.o: %.java. This doesn't seem to be necessary. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
On 16 Dec 2003, Paul D. Smith wrote: %% Bob Friesenhahn [EMAIL PROTECTED] writes: bf Per-subdirectory rules and definitions can be added in order to bf significantly reduce the amount of redundant code, and to bf re-enable the capability to usefully override parts of the default bf Makefile.in. Not if you want to continue to generate portable makefiles. There is no way in POSIX make (for example) to generate a target in a subdirectory using a suffix rule. Bummer. I wasn't sure about that. At the very least, an effort could be made to decrease the Makefile size by making maximum use of macro substitutions. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
Another thing that would help reduce Makefile size is to introduce synonyms for subdirectory paths. For example, java/awt/print/$(DEPDIR)/ could be reduced to $(am_f123). This would of course obfusticate the Makefile, so it should be made optional, or allow the user to specify part of the name so it is still comprehensible. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
I would like to point out that my previous gripe about the unnecessary translation of Automake target names (particularly when the target includes a path), and the subsequent proposal to add user-level target synonyms, dovetails nicely with the need to reduce the Makefile size. The synonyms can help eliminate the size increase caused by the directory path itself. For typical subdirectory path lengths, this could result in a 40% Makefile size reduction. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
On Tue, 16 Dec 2003, Alexandre Duret-Lutz wrote: Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob Another thing that would help reduce Makefile size is to Bob introduce synonyms for subdirectory paths. Better: LZW compression using Makefile variables. Any taker? wink Is this your way of poking fun at my idea? :-( Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
On Wed, 17 Dec 2003, Lars Hecking wrote: What about an automake option then to generate Makefiles for GNU make? How about a new binary 'automake' program that doesn't require an external 'make' program at all? It would read the Makefile.am files directly ... Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
On Thu, 18 Dec 2003, Ralf Corsepius wrote: On Wed, 2003-12-17 at 16:01, Bob Friesenhahn wrote: On Wed, 17 Dec 2003, Lars Hecking wrote: What about an automake option then to generate Makefiles for GNU make? How about a new binary 'automake' program that doesn't require an external 'make' program at all? It would read the Makefile.am files directly ... How many times did you resort to using plain make-rule in Makefile.ams? Plenty. So, IMO, for being useful, you'd either have to extend make to accept the *.am-syntax or to reimplement make. Exactly. The binary 'automake' would be a plain make which also understands Automake syntax. If a non-standard tool is required to be on the user's system in order to build software, then it might as well be a tool that does everything. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: vpath builds and include paths
On Mon, 22 Dec 2003 [EMAIL PROTECTED] wrote: However, if I want to build in a separate build tree (relying on VPATH), then I try the following: mkdir /build cd /build /test/configure make This attempts to build in this new /build directory, but during compilation it cannot locate the header file, myproj.hpp, and the rest of the build fails. What do I need to do in order to tell automake where this header is? I've already tried using the absolute path variables in the Makefile.am: INCLUDE = -I$(abs_top_srcdir)/project2/sublevel/inc Note that abs_top_srcdir calculation was broken in Autoconf 2.58. It is fixed in 2.59. Rather than using INCLUDE you should use AM_CPPFLAGS. For example AM_CPPFLAGS = -I$(top_srcdir)/project2/sublevel/inc Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: automake -vs- huge projects
On Wed, 31 Dec 2003, Alexandre Duret-Lutz wrote: Hmmm. What we'd need to merge are these: .c.o: $(CC) -c -o $@ $ .c.obj: $(CC) -c -o $@ `$(CYGPATH_W) $` [stuff removed] The extension is obviously not an issue, but how can we arrange the CYGPATH_W stuff? An simple (but ugly) approach would be to define $(CYGPATH_W) to 'echo' when not compiling under Cygwin. but this is not really attractive. A related question is why we need this `cygpath -w' stuff. My understanding is that it is to turn special absolute filenames such as /cygdrive/c/foo into c:\foo (if this is true, then I think the first use of $(CYGPATH_W) in the sub/foo.obj rule is superfluous, since the file is relative) so that compiler that do not understand cygwin filename can work. It seems to me that perhaps 'CYGPATH_W' is misnamed or the use is outdated. Cygwin and MinGW's MSYS shell environment already automatically translate paths. The only case where this translation would be necessary is for a shell environment that doesn't automatically translate paths for native Windows binaries, or where the automatic path translation fails. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: config.guess and freedom (was: 1.8 and mkdir_p)
On Tue, 13 Jan 2004, Bob Proulx wrote: If the releases are all that similar, why not use: i686-GnuLinux-* as your test, and provide the popular distributions in the 3rd field? The magic command has a large database of selections on it; using this sort of mechanism should greatly ease the burder on the config.* maintainers. That sounds like the architecture and philosophy of imake. Not exactly. The philosophy of imake is that the imake configuration is primarily vendor maintained. This is/was reasonable for X11 since most vendors were interested in supporting/offering X11. Autoconf does not benefit from that environment. Long ago I wrote a magazine article about Autoconf and feature-based testing (see http://www.byte.com/art/9711/sec4/art2.htm;). At that time feature-based testing was relatively new and was being incorporated in open source packages. Based on the ease of installing most open source packages that provide a configure script, it seems that feature-based testing has proven to be a resounding success. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 1.8 and mkdir_p
On Wed, 14 Jan 2004, Scott James Remnant wrote: On Tue, 2004-01-13 at 21:25, Harlan Stenn wrote: I think you are missing my point. The information I am talking about is used for *runtime* decisions - very likely in a script that is in a shared directory used by many different architectures. Oh, well, config.guess isn't designed for that -- it's for compile time decisions. Config.guess is maintained separately from Automake. It is only distributed by Automake. While it could be viewed as a build tool, it is really a useful utility in its own right and should be treated as such. Regardless of its author's original intentions, I have been known to use config.guess in login scripts, DejaGnu scripts, or for other non-autoconf situations. One handy use when building for multiple architectures is to use config.guess to supply part of the build directory name so that it is very easy to manage heterogeneous builds within one file system. I agree with Harlan that config.guess should produce similar results for Linux as for other operating systems, but apparently the Linux folks disagree since they have intentionally avoided discriminating between Linux distributions. Even Linux 'uname -a' is useless to determine the Linux distribution name. It is way to late to even think about changing things now. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Library dependencies make install
I am using Automake 1.8 with libtool. Automake is doing a good job at building libraries in a correct order based on dependencies (or I could just be lucky) but 'make install' is not paying any attention to library dependencies. It appears that libraries are installed in the same order as specified by lib_LTLIBRARIES. If the ordering of lib_LTLIBRARIES does not jive with the library dependency order, then libtool fails to re-link the library because some libraries it depends are not installed yet. Even worse, it may appear that installation is successful, but some of the libraries are accidentally linked with older versions of the libraries which were already installed. It seems to me that Automake should compute an optimum library installation order based on the specified libtool library (.la) dependencies. This would help ensure that installation errors do not occur due to some hap-hazard lib_LTLIBRARIES list order (e.g. they could be in alphabetical order). Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
RE: Conditional Library Compilation
On Thu, 5 Feb 2004, Drummonds, Scott B wrote: From: Frederik Fouvry [mailto:[EMAIL PROTECTED] You can install it on other places than /usr/share or /usr/local (forgot which one is the default) with But I don't own the large software project that I'm trying to modify. If I upgrade the version of Automake to provide a feature I need in the build environment, it will be my responsibility to validate the existing multi-million line project against the new version. If you're telling me that Automake is 100% forward compatible--that I can upgrade from 1.4 to the newest version and there will be no errors in Automake execution--then I'm on it! But my experience leads me to believe that this is not the case. Automake is very good at telling you about incompatibilities while upgrading. I don't recall Automake misbehaving at run-time due to an incompatibility, but it is possible that it may have happened before and I just don't remember. Upgrading Autoconf is much more of a concern than upgrading Automake. Unfortunately, newer Automake's require newer Autoconfs. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: How to reflect variables like sysconfdir in an executable.
On Sun, 15 Feb 2004, Hans Deragon wrote: I am working on a project where the executable is a Python script, so no building is required. However, since it has to read a configuration file, like /etc/file, my script needs to be modified so that the sysconfdir directory is reflected somewhere. Are there any means with Automake such that an executable script would be parsed and modified with the $sysconfdir variable hardcoded so it knows where to read the configuration file? Couldn't find anything for this in the doc. This is an Autoconf issue, not Automake. Provide a .in version of your script, and then list the desired output file in configure.ac's AC_OUTPUT() statement. Then earlier in configure.ac: FOO=/bar AC_SUBST(FOO) an in the .in file @FOO@ will be substituted with the value of FOO. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: How to reflect variables like sysconfdir in an executable.
On Sun, 15 Feb 2004, Hans Deragon wrote:
Thanks. It almost works. The problem is that it substitute @datadir@ with
${prefix}/share. That is not right. ${prefix} must be expanded. Python
does not understand ${prefix}. Any suggestions? In should be something like
/usr/share in my script.
Do something like
eval eval DATA_DIR=$datadir
AC_SUBST(DATA_DIR)
and then use
@DATA_DIR@
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
Re: html texinfo install?
On Tue, 17 Feb 2004, Karl Berry wrote: The obvious directory would be $(datadir)/html by analogy with $(datadir)/info, but it seems a bit arrogant to use such a generic name for something which only relates to Texinfo manuals. Maybe texinfo/html -- then we could have texinfo/xml/ and texinfo/docbook/ and ..., if we liked. Thus: texinfodata = $(datadir)/texinfo texinfohtml = $(texinfodata)/html Seems fine to me. Also, I'm not sure if make all should make them and make install should install them by default. I'm inclined to say no, because including the HTML in the distributions (which would be the implication) seems like a lot of bloat, and I haven't exactly been flooded with complaints on the subject. Alexandre suggested separate make [un]install-texinfohtml targets, which sounds fine to me. I am against having separate install targets because GNU makefiles normally install everything by default and that is what users should expect. Installing everything is not a problem for distribution maintainers since they decide which files to package using their distribution tools. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: html texinfo install?
On Tue, 17 Feb 2004, Bruce Korb wrote: Bob Friesenhahn wrote: I am against having separate install targets because GNU makefiles normally install everything by default and that is what users should expect. Installing everything is not a problem for distribution maintainers since they decide which files to package using their distribution tools. When you have a tool that produces so many doc formats, I think you want to be able to let the user select what is wanted. If make install implies installing html, then it implies building it, too. That means make needs to imply making the html. Probably the friendliest thing is to let the user select at, say, configure time which form(s) of documentation they want built and installed. --enable-html, --disable-info, --enable-ps, etc. with certain defaults for certain output types. Then, the debate degenerates into whether html should default to enabled or disabled. I'd lean toward disabled, but I don't care much either way This approach is reasonable because then both expectations can be satisfied. Doing 'make install' installs everything which has been requested to be installed. The choice as to whether HTML is installed by default can be left to the package maintainer. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Target-specific CFLAGS
On Tue, 24 Feb 2004, Ben Pfaff wrote: Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? This distinction is not entirely correct since CPPFLAGS is normally supplied to the C++ compiler as well. CFLAGS is for the C compiler and CXXFLAGS is for the C++ compiler. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Target-specific CFLAGS
On Tue, 24 Feb 2004, Ben Pfaff wrote: Bob Friesenhahn [EMAIL PROTECTED] writes: On Tue, 24 Feb 2004, Ben Pfaff wrote: Of course, when my source files are C++ files the _CFLAGS extension does nothing. Changing this to _CPPFLAGS fixed the problem. Duh. You know that CPPFLAGS is for the C preprocessor and CXXFLAGS is for the C++ compiler, right? This distinction is not entirely correct since CPPFLAGS is normally supplied to the C++ compiler as well. CFLAGS is for the C compiler and CXXFLAGS is for the C++ compiler. Well, yes: C++ uses the C preprocessor. Which is not really a great assumption since C++ is a different language and the C++ compiler vendor may not be the same as the C compiler vendor. The behavior of the C++ preprocessing may behave differently. Autoconf and Automake make a lot of assumptions when it comes to C++. Luckily the assumptions are correct more often than not. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: FEATURE REQUEST: make uninstall should delete empty directories.
On Mon, 1 Mar 2004, Hans Deragon wrote: When performing a make uninstall, I notice that it only deletes the files, not the empty directories. It would be nice that after removing a file, it removes all the empty directories recursively. For example: If a package supports creating the directory /usr/local (as Automake does by default) should this directory be recursively removed if a package is uninstalled? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: FEATURE REQUEST: make uninstall should delete empty directories.
On Tue, 2 Mar 2004, Daniel Reed wrote: On 2004-03-02T08:34-0600, Bob Friesenhahn wrote: ) On Mon, 1 Mar 2004, Hans Deragon wrote: ) When performing a make uninstall, I notice that it only deletes the files, ) not the empty directories. It would be nice that after removing a file, it ) removes all the empty directories recursively. For example: ) If a package supports creating the directory /usr/local (as Automake ) does by default) should this directory be recursively removed if a ) package is uninstalled? Not if it is non-empty after everything subordinate to it installed as part of the package has been removed. The reason why I mentioned /usr/local is because it is a shared directory. I could also have mentioned /usr. While it seems nice for a package to 100% clean-up after itself, a bug could cause the package uninstall to accidentally remove the operating system. It is not always easy to see if a directory is empty. For example, when NFS is being used, sometimes .nfs files are created in the directories, so the directory is not really empty. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: FEATURE REQUEST: make uninstall should delete empty directories.
On Thu, 4 Mar 2004, Andrew Suffield wrote: Thus, if I'm right that Automake doesn't know which directories the package owns, it should should err on the side of caution: it should *not* try to delete any empty directories at uninstall time. Neither should Automake try to guess -- guesses involving the rm command, especially as root, are a really dangerous idea! That's why you use the rmdir command. Semantics equivalent to 'rmdir' may not be available on non-Unix operating systems. Automake doesn't just run under Unix. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Problems installing dependant libraries
On Fri, 12 Mar 2004, Fredrick Meunier wrote: Hi, I have just come across the same problem raised in the thread Library dependencies make install on the automake lists in January this year (http://mail.gnu.org/archive/html/automake/2004-01/msg00145.html) in a reasonably large project. The last message in the thread from Alexandre Duret-Lutz suggests: Another idea is to split the installation procedure in two steps: copy all libraries, and once it is done relink all libraries. Would that work? If so, we need a way to tell libtool to copy libraries without relinking. The fundamental problem is that Automake does not have an overall coherent understanding of the library dependencies when libraries are built using a recursive build. Without understanding the library dependencies, it is difficult to see how relinking would work. Relinking the libraries using an arbitrary order is unlikely to work even if all the libraries are present since then the wrong embedded library dependencies (for systems which support the notion) may be picked up. It seems that libtool already avoids relinking for DESTDIR installs, and expects the user to use 'libtool --finish' at install time (a step which is usually forgotten). That means that libtool already understands how to do a delayed relink. So the solution is for someone to come up with a way that Automake can have a coherent understanding of library dependencies (which are already specified piecemeal in individual Makefile.am files). One way to accomplish this may be to maintain a top-level file which records the order that libraries were linked during the build. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: shared library suffix
On Sat, 10 Apr 2004, Alien9 wrote: In the config.h file, i need to know what the shared library suffix is on the configured system. do you guys know how that is accomplished? the purpose is to use dlopen with a path, so i need to have the complete filename of a library, therefor i must know the suffix... You should use libtool for this task. Automake is designed to work with libtool to build shared libraries, and libtool supports portable shared library dlopening via its libltdl component. Libtool stores the compile filename of the library in an associated .la file. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: shared library suffix
On Mon, 12 Apr 2004, Alien9 wrote: so how can i get it out of that .la file? If you can locate the .la file then it should be as simple as eval `grep 'dlname=' $file` Since the line looks like dlname='libpstoedit.so.0' Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [Bug-tar] Re: AMTAR brokenness
On Fri, 16 Apr 2004, Alexandre Duret-Lutz wrote: By the way, the pax manpage from the Heirloom Toolchest (http://heirloom.berlios.de/man/pax.1.html) mentions that due to implementation errors, file names longer than 99 characters can not considered to be generally portable when taking about the ustar format. I think it's the only place where I've read this. Has anybody seen such implementation? I'm tempted to think we shouldn't care. More than likely such implementations exist. Usually when tar programs break while extracting long file names, they continue on, leaving bad file names in their wake. Probably the user won't even notice until something doesn't work. Is there a reason to allow file names longer than 99 characters in a package? Clearly this is non-portable. Why not enforce a maximum file name length of 99 characters in Automake? One way to enforce this is to use sed to truncate file names longer than 99 characters before passing them to tar so that tar complains/fails during 'make dist'. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Automake 1.8.3 doesn't build?
Failure to configure and build Automake is a first for me. This is under FreeBSD 5.0: % ./configure configure: loading site script /usr/local/share/config.site CC = /usr/local/bin/gcc-3.3.3 CXX = /usr/local/bin/c++-3.3.3 CFLAGS = -O2 -Wall -march=i686 -mcpu=pentium4 -pipe CXXFLAGS = -O -Wall -march=i686 -mcpu=pentium4 -pipe CPPFLAGS = -I/usr/local/include LDFLAGS = -L/usr/local/lib -R/usr/local/lib -R/usr/X11R6/lib checking build system type... i386-unknown-freebsd5.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for perl... /usr/local/bin/perl checking for tex... no checking whether autoconf is installed... yes checking whether autoconf works... yes checking whether autoconf is recent enough... yes checking whether ln works... yes checking for grep that handles long lines... checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating lib/Automake/Makefile config.status: creating lib/Automake/tests/Makefile config.status: creating lib/Makefile config.status: creating lib/am/Makefile config.status: creating m4/Makefile config.status: creating tests/Makefile config.status: creating tests/defs config.status: creating tests/aclocal-1.8 config.status: creating tests/automake-1.8 shaggy:src/gnu/automake-1.8.3% gmake Making all in . doc m4 lib tests cd: no such file or directory: . doc m4 lib tests gmake: *** [all-recursive] Error 1 % gmake --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Automake 1.8.3 doesn't build?
Apparently the key to building Automake 1.8.3 under FreeBSD is to use BSD make rather than GNU make. However, Automake 1.8.2 configures and builds just fine using GNU make. Bob On Sat, 17 Apr 2004, Bob Friesenhahn wrote: Failure to configure and build Automake is a first for me. This is under FreeBSD 5.0: % ./configure configure: loading site script /usr/local/share/config.site CC = /usr/local/bin/gcc-3.3.3 CXX = /usr/local/bin/c++-3.3.3 CFLAGS = -O2 -Wall -march=i686 -mcpu=pentium4 -pipe CXXFLAGS = -O -Wall -march=i686 -mcpu=pentium4 -pipe CPPFLAGS = -I/usr/local/include LDFLAGS = -L/usr/local/lib -R/usr/local/lib -R/usr/X11R6/lib checking build system type... i386-unknown-freebsd5.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for perl... /usr/local/bin/perl checking for tex... no checking whether autoconf is installed... yes checking whether autoconf works... yes checking whether autoconf is recent enough... yes checking whether ln works... yes checking for grep that handles long lines... checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating lib/Automake/Makefile config.status: creating lib/Automake/tests/Makefile config.status: creating lib/Makefile config.status: creating lib/am/Makefile config.status: creating m4/Makefile config.status: creating tests/Makefile config.status: creating tests/defs config.status: creating tests/aclocal-1.8 config.status: creating tests/automake-1.8 shaggy:src/gnu/automake-1.8.3% gmake Making all in . doc m4 lib tests cd: no such file or directory: . doc m4 lib tests gmake: *** [all-recursive] Error 1 % gmake --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Automake 1.8.3 doesn't build?
On Sun, 18 Apr 2004, Alexandre Duret-Lutz wrote: Bob, I've built Automake 1.8.3b with the latest CVS Autoconf. Could you check whether that fixes your problem? ftp://alpha.gnu.org/gnu/automake/automake-1.8.3b.tar.bz2 Still fails: % gmake Making all in . doc m4 lib tests cd: no such file or directory: . doc m4 lib tests gmake: *** [all-recursive] Error 1 % grep 'SHELL =' Makefile SHELL = /bin/zsh Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Automake 1.8.3 doesn't build?
On Sun, 18 Apr 2004, Alexandre Duret-Lutz wrote: I bet the only difference between the official 1.8.3 tarball and the one you generated is that the former tarball uses CVS Autoconf. 1.8.2 and your regenerated version likely use Autoconf 2.59. That is true, I am using Autoconf 2.59. It doesn't seem right to use unreleased software to produce formal GNU distributions. This suggests that shell running this code does not split $list and $subdir get the full list. Zsh would do that. Could you compare the output of grep 'SHELL =' Makefile on the working and non-working tarballs? Working: % grep 'SHELL =' Makefile SHELL = /bin/bash Non-working: % grep 'SHELL =' Makefile SHELL = /bin/zsh It is true that my login shell is /bin/zsh. This has never caused a problem before (I have been using zsh as my shell since 1996). Even if zsh is used, there are well-documented ways to tell Zsh to split arguments like the Bourne shell does. Unfortunately, this would require that extra cruft appear in the Makefiles. CVS Autoconf has a new SHELL selection code. That could explain it. Sounds like it is broken. It is incorrect to assume that the user's login shell is the shell that should be used. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Automake 1.8.3 doesn't build?
On Sun, 18 Apr 2004, Eric Sunshine wrote: CVS Autoconf looks for a shell which supports functions and $LINENO. Apparently, your zsh satisfies those requirements, so Autoconf is happy with it. Even if zsh is used, there are well-documented ways to tell Zsh to split arguments like the Bourne shell does. Unfortunately, this would require that extra cruft appear in the Makefiles. Indeed, Autoconf invokes the goop to tell Zsh to split like Bourne, but this doesn't help Automake-generated makefiles. Can you apply the following manual edit to the configure script (not the configure.ac file) and report if it fixes the problem? In configure, find the line: as_candidate_shells=$SHELL Change it to: as_candidate_shells= If that resolves the problem, I will submit an appropriate patch for Autoconf. This change resolves the problem. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Automake 1.8.3 doesn't build?
Regarding use of Zsh, is it not possible to add options to the SHELL definition so that even if Zsh is the selected shell, it will properly split arguments. For example, in my Zsh manual page, I see that the -y option enables SH_WORD_SPLIT so presumably SHELL = /bin/zsh -y should emulate the Bourne shell in this respect. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
'make distcheck' fails due to Automake
I am once again experiencing problems with Automake leaving behind the distribution files it built so 'make distcheck' fails: ERROR: files left in build directory after distclean: ./GraphicsMagick-1.2.020040419.tar.gz ./GraphicsMagick-1.2.020040419.tar.bz2 ./GraphicsMagick-1.2.020040419.zip gmake[1]: *** [distcleancheck] Error 1 gmake[1]: Leaving directory `/usr/home/bfriesen/build/GraphicsMagick-8-static/GraphicsMagick-1.2.020040418/_build' % automake --version automake (GNU automake) 1.8.3 This is under FreeBSD 5.X. What steps should I take to find the cause of this problem? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 'make distcheck' fails due to Automake
I should mention that changing to the source directory and executing 'automake --force' seems to clear up this problem when it occurs. It seems that there must be an ordering problem to maintainer-mode activities which results in the tarballs not being removed properly. I have seen the problem three times already while using Automake 1.8.3. I did not see it with 1.8.2 (which was used for quite a while), but I did see it several minor releases back (don't remember which). Bob On Tue, 20 Apr 2004, Bob Friesenhahn wrote: I am once again experiencing problems with Automake leaving behind the distribution files it built so 'make distcheck' fails: ERROR: files left in build directory after distclean: ./GraphicsMagick-1.2.020040419.tar.gz ./GraphicsMagick-1.2.020040419.tar.bz2 ./GraphicsMagick-1.2.020040419.zip gmake[1]: *** [distcleancheck] Error 1 gmake[1]: Leaving directory `/usr/home/bfriesen/build/GraphicsMagick-8-static/GraphicsMagick-1.2.020040418/_build' % automake --version automake (GNU automake) 1.8.3 This is under FreeBSD 5.X. What steps should I take to find the cause of this problem? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 'make distcheck' fails due to Automake
On Wed, 21 Apr 2004, Ralf Corsepius wrote: On Wed, 2004-04-21 at 04:35, Bob Friesenhahn wrote: I am once again experiencing problems with Automake leaving behind the distribution files it built so 'make distcheck' fails: ERROR: files left in build directory after distclean: ./GraphicsMagick-1.2.020040419.tar.gz ./GraphicsMagick-1.2.020040419.tar.bz2 ./GraphicsMagick-1.2.020040419.zip gmake[1]: *** [distcleancheck] Error 1 gmake[1]: Leaving directory `/usr/home/bfriesen/build/GraphicsMagick-8-static/GraphicsMagick-1.2.020040418/_build' % automake --version automake (GNU automake) 1.8.3 This is under FreeBSD 5.X. What steps should I take to find the cause of this problem? I don't know what causes your problems, but note the versions used above: 020040419 vs. 020040418 Good catch. For snapshot builds, my project does not hard-code the version in the configure.ac file. Instead it uses a scrap of shell code to compute the version (at configure time) based on the last ChangeLog entry. In fact, all of the package versioning is controlled from a separate file since it doesn't make sense to me to modify configure.ac just to set the package version. This has eased maintenance considerably. If Automake uses the timestamp of configure.ac but doesn't compare the package version, then it seems that the build environment can get confused. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: autoconf 1.x for vms maintainership request
On Tue, 27 Apr 2004, Thien-Thi Nguyen wrote: i posted the following to the autoconf list: http://mail.gnu.org/archive/html/autoconf/2004-04/msg00131.html but perusing the archive shows that list is mostly full of (other) junk, hence this post, in case autoconf maintainers have decided to avoid that list. Autoconf 1.12 is an anchient legacy version dating from eight years ago. The current Autoconf is 2.59. If no one responded, it was probably because your request was similar to proposing a design change to the Model T Ford. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: libtool verbosity
On Mon, 17 May 2004, Jan Beulich wrote: Wouldn't it make sense to have automake generate the LIBTOOL variable by default so that libtool's verbosity matches that of make, i.e. by something like LIBTOOL = @LIBTOOL@ $(if $(findstring s,$(filter-out --%,$(MAKEFLAGS))),--silent) This looks like GNU make syntax to me. Automake does not (and should not) depend on GNU make. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: libtool verbosity
On Mon, 17 May 2004, Jan Beulich wrote: I was expecting this sort of answer, but was hoping that then I would also get a pointer to how else to possibly achieve the same thing. For the package I support, I added a configure option to enable verbose libtool output. Libtool is executed in silent mode by default since it is assumed that maintainers/porters are the only ones who really need the extra information. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: libtool verbosity
On Thu, 20 May 2004, Albert Chin wrote: On Mon, May 17, 2004 at 11:24:49AM -0500, Bob Friesenhahn wrote: On Mon, 17 May 2004, Jan Beulich wrote: I was expecting this sort of answer, but was hoping that then I would also get a pointer to how else to possibly achieve the same thing. For the package I support, I added a configure option to enable verbose libtool output. Libtool is executed in silent mode by default since it is assumed that maintainers/porters are the only ones who really need the extra information. Why would anyone want silent output? Surely someone building your tool would be interested in errors during a build, rather than rebuilding from scratch to find out what went wrong? Errors are certainly printed. What is not printed are the steps that libtool is taking to perform the requested commands. The result is 1/4 to 1/3 the output while building. If libtool should happen to fail (gasp!) then it is useful for it to print everything it is doing. Luckily libtool rarely fails these days so verbose output is perhaps best left for people developing/debugging libtool. If you *really* want to know what is going on, then I suggest that you always add -vH to CPPFLAGS and CFLAGS so that the compiler can tell you exactly what it is doing. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Need a way to pass options to libtool
Currently Automake Makefiles include text like: LTCXXCOMPILE = $(LIBTOOL) --mode=compile $(CXX) $(DEFS) \ $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ $(AM_CXXFLAGS) $(CXXFLAGS) Notice that there is no means provided to add libtool specific options. The only means available is for the user to cut-and-past this chunk into their Makefile.am so that it overrides Automake's default. This has long term negative effects for Automake. I recommend that Automake definitions which specify how libtool is used include a place to add libtool options for that mode. For example LTCXXCOMPILE = $(LIBTOOL) $(LTCXXCOMPILEOPTS) --mode=compile $(CXX) $(DEFS) \ $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ $(AM_CXXFLAGS) $(CXXFLAGS) This way the user could specify a value for LTCXXCOMPILEOPTS and does not need to replace the entire text. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: excessive bounces
On Wed, 26 May 2004, Ralf Corsepius wrote: Face it, this is not 1994 anymore, the internet has lost its innocence, and badly maintained open lists like the auto*tools lists on gnu.org are a relict of the past. Unfortunately, SPAMmers quickly learn how to break through automated defenses so that they can simply subscribe to lists. One way or another, list servers are simply overwelmed. There seems to be no reasonable solution. I believe that all of the SourceForge lists are also open. They used to support blocking non-subscribers but that became a nightmare for maintainers so the capability was removed. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Need a way to pass options to libtool
On Tue, 25 May 2004, Albert Chin wrote: On Sun, May 23, 2004 at 03:20:35PM -0500, Bob Friesenhahn wrote: Currently Automake Makefiles include text like: LTCXXCOMPILE = $(LIBTOOL) --mode=compile $(CXX) $(DEFS) \ $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ $(AM_CXXFLAGS) $(CXXFLAGS) Notice that there is no means provided to add libtool specific options. The only means available is for the user to cut-and-past this chunk into their Makefile.am so that it overrides Automake's default. This has long term negative effects for Automake. Why not: AM_CXXFLAGS += [your additions] It is indeed true that after I posted I realized that my libtool syntax usage was incorrect and that CFLAGS/CXXFLAGS could be used for this purpose. Sorry for the distraction. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: excessive bounces
On Thu, 27 May 2004, Lars Hecking wrote: o gnu.org has a prohibitively high volume of email, and SA/Bayes require massive resources. Therefore, the volume of mail going through SA or any other tool must be limited. Bogofilter does a fine job of Bayesian filtering and is 50-100X faster than SpamAssassin. Surely it does not offer the extra features of SpamAssassin, but using it would help considerably, and should keep up with gnu.org performance requirements. o Excessive whitelisting: all current gnu.org subscribers should be white- listed, so that their email bypasses anti-spam. Yes, that'll still leave the problem of subscribed spammers, but I believe there won't be too many. This does not work at all. A huge amount of email I receive are bounces or anti-SPAM notices from forged emails sent using my address. More than likely I have received many SPAM emails claiming to be from Lars Hecking. :-) o Ruthless use of DNS blacklists before mails reach anti-spam. Most of spam on GNU lists originates from known bad boys - Korea, China, dialup/dyn-ip hosts, Comcast, *bell etc. Recommended reading: http://makeashorterlink.com/?D20312968. sbl-xbl.spamhaus.org alone would probably work wonders. Usually this is good, but lately I have been noticing that substantial email is arbitrarily rejected due temporary local DNS issues or bugs. It is not pleasant to be on the wrong end of this. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Need a way to pass options to libtool
On Sat, 29 May 2004, Alexandre Oliva wrote: On May 26, 2004, Albert Chin [EMAIL PROTECTED] wrote: On Sun, May 23, 2004 at 03:20:35PM -0500, Bob Friesenhahn wrote: Notice that there is no means provided to add libtool specific options. Why not: AM_CXXFLAGS += [your additions] Because that's also passed to non-libtool compilations? I've often wanted some means to pass additional flags to libtool compile and/or link commands without affecting non-libtool compile and/or link. My favorite example is -static, that has a somewhat different meaning when it comes to libtool. And -static was exactly the option that I was seeking to pass. :-) Luckily, my Makefile.am doesn't include any non-libtool compilations. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
rsync to copy files?
A package I am working with needs to install many large files. In the course of package development it is necessary to execute 'make install' many times. These large files never change. I have learned that using 'rsync' to copy files improves the install time quite dramatically for repeat installs. Even for files that change sometimes (executables, libraries, formatted documentation), it is quite common for subsequent installs to copy identical files since the files are already built/generated. Perhaps automake might consider checking for 'rsync' and making use of it if it is available (and works)? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: rsync to copy files?
On Wed, 23 Jun 2004, Warren Young wrote: Bob Friesenhahn wrote: I have learned that using 'rsync' to copy files improves the install time quite dramatically for repeat installs. This should only be true when the transfer channel is much slower than the disks on which the files are stored. rsync must read both the source and destination files, and do calculations on both, before it knows which parts of the files need to be transferred. When the transfer channel is a network, it's likely that the time spent doing this extra disk I/O and calculation is more than offset by the savings in network time. When the source and destination are on the same machine, there should be no such benefit. That is true. However, usually reading is faster than writing, particularly if NFS is involved. Also, rsync can first check both the file's timestamp and size. In my test case, the source files are accessed via NFS (over 100BASE-T), and the 'make install' is executed on the target system. Instead of chasing this solution, try patching autoconf to use 'cp -u' instead of 'install'. I was not aware of this cp option. It seems to be limited to GNU cp. On Linux systems, or systems where GNU cp is available, this seems like a reasonable choice. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: rsync to copy files?
On Thu, 24 Jun 2004, Ralf Wildenhues wrote: an easy way to replace 'install' is to overwrite the INSTALL variable temporarily (at least with gnu make): make INSTALL=myinstall install Yes, I know, thank you. I was not referring to a particular way to install a particular software, but rather to the way the Automake install rules should work. Say, I test a package in a second build tree with different compile options, and then decide to re-install the old package from the first build tree, I do not want to end up with a mixed installation even if I forgot to 'make uninstall' in between. I just would not expect 'make install' to behave that way. Does that make the intention of my comment clear? Yes, very. From comments posted it seems that we can summarize: o Any alternative to install/cp should not be the default, even if the necessary tools are found since performance improvements depend on the relative performance of the filesystems involved (and there may be no improvement at all if the file must actually be copied and both files are on local disk). o The replacement must reliably update the file if it has changed. I believe that rsync looks at the absolute time stamp (with optional fuzz factor) while it seems that GNU 'cp -c' only checks the source file's date to see if it is newer and does not check file size. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: anti-spam, please?
On Mon, 12 Jul 2004, Adam Monsen wrote: Could we please get some anti-spam protection on this mailing list? There's almost more noise than signal. I don't see this noise since I use bogofilter to filter out almost all SPAM (500-1000 SPAM messages/day). However, recently I have encountered lots of problems with sites that won't accept my mail due to poorly-implemented anti-SPAM measures. If there is a trade-off, I would rather receive (and filter) SPAM than not be able to post to lists. There is an apparent FSF policy that non-subscribers should be able to post to GNU mailing lists. This policy is one reason why there is so much SPAM on the lists. The alternative is that many useful postings would not be posted to the lists. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [PATCH] add cscope tags target
On Wed, 14 Jul 2004, Jesse Barnes wrote: Now that cscope is free software, I thought it might be nice if automake created make targets for it. It's a powerful too; very useful for large projects. Here's a patch that implements it in tags.am. If it looks ok, can someone please commit it so it's part of the next release? It looks like this rule will include source files which are not incorporated by Makefile.am since it appears to simply recurse through the source tree. That means it may pick up source files from other projects, or source files which are not in use. Is that what you intended? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [PATCH] add cscope tags target
On Wed, 14 Jul 2004, Jesse Barnes wrote: It looks like this rule will include source files which are not incorporated by Makefile.am since it appears to simply recurse through the source tree. That means it may pick up source files from other projects, or source files which are not in use. Is that what you intended? Kind of. It looks like gtags does that, so I followed its example. It might be better to only include those explicitly listed by Makefile.am, but I wasn't sure of the best way to get the full list of source files... OTOH, maybe it's best to index the whole project. Probably gtags is not implemented very well. It seems like there should be a rule to collect the source file list from all Makefiles (including subordinate Makefiles) followed-up by another rule which actually executes cscope using the file list. If the build is a VPATH build, then the source directory tree should be treated as read-only, with the cscope database being built in the build directory. This allows multiple architectures to use cscope without trashing each other's databases (the cscope database format appears to be architecture dependent). Indexing everything under the source tree doesn't make sense since the software may not be related, or there may replicated source files. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [PATCH] add cscope tags target
On Wed, 14 Jul 2004, Jesse Barnes wrote: On Wednesday, July 14, 2004 3:59 pm, Bob Friesenhahn wrote: Probably gtags is not implemented very well. Sounds like it. It seems like there should be a rule to collect the source file list from all Makefiles (including subordinate Makefiles) followed-up by another rule which actually executes cscope using the file list. That's where I got stuck. If there were such a rule, it would be easy to dump the filelist into cscope.files in the top level of the build directory and pass that as an argument to cscope. It should be no different than other recursive Automake rules (e.g. 'dist'). Each Makefile.am would concatenate its own source file list to a 'cscope.files' in the top level of the build directory. Once the rule in all the Makefile.am's has been executed, cscope would be executed. In fact, I think that the existing 'make dist' is the best example of this because it is pretty similar. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
distcheck bug
There is an Automake bug in 'make distcheck' which is causing me considerable pain. The problem is that while configuring subordinate builds, Automake allows configure to use any old compiler rather than the one specified with CC or CXX while configuring the project. In spite of using any old compiler, it takes great care to pass other user-provided options (e.g. -L options) to the subordinate builds. This bug causes 'make distcheck' to needlessly fail for me when I specify the use of a 64-bit compiler, and a linker search path suitable for that compiler. The subordinate builds end up using a 32-bit compiler along with options which only work for the 64-bit compiler so 'make distcheck' fails. Is use of any old compiler accidental or intentional? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: distcheck bug
On Fri, 16 Jul 2004, Alexandre Duret-Lutz wrote: Bob == Bob Friesenhahn [EMAIL PROTECTED] writes: Bob There is an Automake bug in 'make distcheck' which is causing me Bob considerable pain. See DISTCHECK_CONFIGURE_FLAGS is the manual. Interesting. So if I want Automake to re-use the standard variable settings passed to the original configure, I need to make it explicit like DISTCHECK_CONFIGURE_FLAGS=CC=$(CC) CXX=$(CXX) ? It seems that LDFLAGS is being passed but not CC and CXX even though those were also specified on the configure command line. Why aren't all the standard Autoconf variables saved and replayed? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: distcheck bug
On Thu, 15 Jul 2004, Bob Friesenhahn wrote: It seems that LDFLAGS is being passed but not CC and CXX even though those were also specified on the configure command line. Why aren't all the standard Autoconf variables saved and replayed? I was wrong. It seems that the user specified LDFLAGS is not passed to configure either. So now I am testing with DISTCHECK_CONFIGURE_FLAGS='CC=$(CC)' 'CXX=$(CXX)' 'CPPFLAGS=$(CPPFLAGS)' 'LDFLAGS=$(LDFLAGS)' Unfortunately, these values may be extended or altered by the time they are saved in the Makefile. It will extra configure work to preserve the user-provided values. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: distcheck bug
On Fri, 16 Jul 2004, Andrew Suffield wrote:
I habitually do something like this anyway (duplicated for every
variable I mangle in configure):
orig_CFLAGS=$CFLAGS
[detect some stuff...]
CFLAGS=$foo_CFLAGS $bar_CFLAGS $orig_CFLAGS
[detect some more stuff...]
CFLAGS=$foo_CFLAGS $bar_CFLAGS $baz_CFLAGS $orig_CFLAGS
Since that's the only sane way I can come up with to make
'CFLAGS=foo ./configure' work, and still keep a complicated configure.ac
readable. So I'd just AC_SUBST(orig_CFLAGS) and stuff that into
DISTCHECK_CONFIGURE_FLAGS, under the assumption that the configure
script is supposed to sort it out given that input.
This is the scheme I plan on using to pass the key environment
variables to the Makefile:
for var in CC CFLAGS CPPFLAGS CXX CXXCPP LDFLAGS LIBS ; do
eval isset=$\{`echo $var`'+set'\}
if test $isset = 'set' ; then
eval val=$`echo $var`
DISTCHECK_CONFIG_FLAGS=${DISTCHECK_CONFIG_FLAGS}'${var}=${val}'
fi
done
AC_SUBST(DISTCHECK_CONFIG_FLAGS)
The chunk of code is placed shortly after AC_INIT. Probably there is
some better syntax but it seems to work.
The old days of Autoconf you couldn't specify environment variables as
configure arguments. If you set them in the shell environment, this
situation wouldn't exist since subordinate configures would pick them
up. If you set them only in configure's environment, then the problem
would exist.
Perhaps there is some reason why Automake shouldn't assure that these
values are passed to subordinate distcheck configures, but I can't
think of one.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
Re: perl ExtUtils::MakeMaker + Autotools
On Thu, 15 Jul 2004, Stony Yakovac wrote: I have a project which I have put under autotools which has several perl packages associated with it. One of them is swigged, two are pure perl. The dilemma is not building for development, I was able to do that with the install-exec-hook, the dilemma is how to get the whole project past distcheck. I have been trying for weeks now. I have gone from putting all kinds of support in the Makefile.am files to trying to duplicate the functionality of automake in ExtUtils::MakeMaker (which required some fairly significant changes to ExtUtils::MakeMaker) Has anyone done this? I have searched the web, but have not been happy with what I found. Does anyone have suggestions? When the wind is blowing right, I have achieved this in GraphicsMagick (http://www.GraphicsMagick.org/) by using hooks in the top Makefile.am. These are aware of MakeMaker subtargets. The Perl extension is built static by default, which avoids issues with shared libraries, and convincing Perl to find/load the module. If your project does not absolutely require the Perl component you could have it disabled by default, or (as I learned yesterday), you can include the configure option to disable it while doing distcheck in DISTCHECK_CONFIGURE_FLAGS. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: libtool relink problems with multiple libtool libraries
On Thu, 29 Jul 2004, J.T. Conklin wrote: Everything builds fine, but a make install fails with a libtool first complaining that it has to relink libFOO.la, which fails because the linker can't find -lBAR -- probably because the BAR and BAZ libraries haven't been installed yet. Is there any way to describe this install dependency in automake? Is reordering the libraries in the Makefile.am necessary and/or sufficent? This is an on-going problem with Automake and difficult to solve. The only current solution is to carefully order the list of libraries so they happen to be installed in a working order. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Implementing Automake in Scheme
It seems to me that the plan to implement Automake in Scheme is a failed scheme which was suggested by [EMAIL PROTECTED] back in the days when Guile Scheme were described to be superior to Perl and Tcl. Bob On Thu, 5 Aug 2004, Luis Araujo wrote: Hello , Greetings I email to ask you for further information about a task in the section GNU Help Wanted in savannah, named Implement automake in Scheme , there is a brief description about it, but i cant find any links pointing to such project. Im kind of interesting, and i would like to know if anybody is already working on it, and if it is so, how i can get in contact with the project. Thanks --- Luis == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Implementing Automake in Scheme
On Sat, 7 Aug 2004, Norman Gray wrote: On Thu, 5 Aug 2004, Luis Araujo wrote: I email to ask you for further information about a task in the section GNU Help Wanted in savannah, named Implement automake in Scheme , there is a brief description I didn't know there was such a thing as the `GNU Help Wanted' list, but I've long thought such a project would be an excellent idea. It's a pretty natural language for such a task, and quite a few of the important bits of automake.in are, it seems to me, written in a pretty functional style anyway. And scsh is POSIX, portable, and pretty lightweight. Automake is already written. It took years. Perl is already installed on most machines. Scheme is not. It is surely a waste of time to re-implement something simply because it does not use a FSF-preferred language. There must be something more useful for volunteers to work on. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Automake includes bug
Using Automake 1.9.1 Perl 5.8.4 there is a bug with file inclusion. Out of the lines: include $(srcdir)/config/Makefile.ami include $(srcdir)/ltdl/Makefile.ami include $(srcdir)/magick/Makefile.ami include $(srcdir)/coders/Makefile.ami include $(srcdir)/filters/Makefile.ami include $(srcdir)/Magick++/Makefile.ami include $(srcdir)/wand/Makefile.ami include $(srcdir)/utilities/Makefile.ami all of the inclusions work correctly except for the line include $(srcdir)/Magick++/Makefile.ami which is transposed directly into the Makefile.in file without otherwise being processed by Automake. Is there a fix or workaround for this other than altering the source tree or moving the file? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: non-recursive make and tests
On Mon, 30 Aug 2004, Bob Friesenhahn wrote: It would be quite helpful if Automake offered a mode in which it automatically changed the working directory to the directory where the test program/script resides and set $srcdir to the relative position in the source tree to support VPATH builds. This would emulate the operation of recursive builds. Either a global Automake option could be used to enable this (subdir-tests), or a RTESTS (relative tests) mode would be provided. It seems that this topic has not caught anyone's interest since there have been no follow-up posts today. Surely someone else has converted their recursive project to a non-recursive project and noticed that it is very difficult to get test suites working again? The current check-TESTS definition works great for recursive builds, but is miserable for non-recursive builds. The $(srcdir) value passed is often essentially useless since it may just be '.'. It is difficult for the Makefile to produce better values except for perhaps offsets from @abs_top_srcdir@ and @abs_top_builddir@ substitutions. It may also be possible to play games by passing back-ticked shell script fragments rather than normal values in the TESTS_ENVIRONMENT specification. Regardless, the tests themselves should not have to know their position in the source or build tree. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: non-recursive make and tests
On Tue, 31 Aug 2004, Robert Collins wrote: On Mon, 2004-08-30 at 20:30 -0500, Bob Friesenhahn wrote: On Mon, 30 Aug 2004, Bob Friesenhahn wrote: It would be quite helpful if Automake offered a mode in which it automatically changed the working directory to the directory where the test program/script resides and set $srcdir to the relative position in the source tree to support VPATH builds. This would emulate the operation of recursive builds. Either a global Automake option could be used to enable this (subdir-tests), or a RTESTS (relative tests) mode would be provided. It seems that this topic has not caught anyone's interest since there have been no follow-up posts today. Surely someone else has converted their recursive project to a non-recursive project and noticed that it is very difficult to get test suites working again? I found it trivial. Mind you, all my tests are - by design - self contained. Most of the tests for the package I maintain require that the test read an existing input file, and write an output file. Sometimes the written result needs to be compared with another existing file. For scripts I can find the source directory (where input files are stored) by doing something like SRCDIR=`dirname $0`/ in the script. Unfortunately, this cludge is apparently not working if the build directory is under the source tree, so distcheck is failing. Probably another layer of cludges is required. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: non-recursive make and tests
On Mon, 30 Aug 2004, Bob Friesenhahn wrote:
The $(srcdir) value passed is often essentially useless since it may just be
'.'. It is difficult for the Makefile to produce better values except for
perhaps offsets from @abs_top_srcdir@ and @abs_top_builddir@ substitutions.
It may also be possible to play games by passing back-ticked shell script
fragments rather than normal values in the TESTS_ENVIRONMENT specification.
Regardless, the tests themselves should not have to know their position in
the source or build tree.
If I add this sort of junk to the top of my test scripts then they
seem to pass the tests:
set -e
SRCDIR=`dirname $0`
SRCDIR=`cd $SRCDIR pwd`
TOPSRCDIR=`cd $srcdir pwd`
cd utilities || exit 1
MODEL_MIFF=${TOPSRCDIR}/Magick++/demo/model.miff
.
.
.
Without the pwd's distcheck can't pass since srcdir may be passed as a
useless '.'.
Unfortunately, with hundreds of such scripts, altering the test
environment to convert to a non-recursive make is quite a penalty.
Many scripts could be one-liners if Automake can produce a
per-directory test environment.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
Re: non-recursive make and tests
On Tue, 31 Aug 2004, Gary V.Vaughan wrote: Many scripts could be one-liners if Automake can produce a per-directory test environment. I made a stab at converting libtool to non-recursive make last year (I think) and had much the same problem. I think the general solution is to move to an Autotest based testsuite, where the input files are generated by the test rather than searched for in the source tree. Maybe you can emulate that behaviour by making your test input into here documents in the test scripts, without a whole scale move to Autotest? That sounds great, but in my case the input files are graphic image files so they would be rather unwieldy in here documents. Typically a file is read, processed using an algorithm, and then either its checksum is compared with a reference checksum, or the final output is compared with reference data. There are lots of other types of software packages with tests that have similar requirements. The easiest solution is to update the check-TESTS: definition in automake's lib/am/check.am file so that it has an option to emulate the way a test would traditionally be executed by a recursive build. I can hack my copy of Automake, but then the resulting project can't be re-created by someone else. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Autoconf 2.59 doesn't work with automake-1.9
On Wed, 1 Sep 2004, Stephen torri wrote: Autoconf 2.59 doesn't work with automake 1.9 for some reason. I made conftest.ac with only AC_INIT in it and ran autoconf manually it completed fine with no errors. I did: I saw this problem just yesterday. I had just installed Autoconf and Automake. Turns out that the new Autoconf was not in my PATH. Make sure that 'autoconf --version' (from your path) reports the expected version. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
