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 > > > #! /bin/sh > ccache g++ "$@" > > > 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? 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
On Thu, 8 Jan 2004, Gary V.Vaughan wrote: > > > Another problematic case is ensuring "correctness" of guess-derived > > results. Without additional checks, you can't guarantee anything. > > Eg. wrt. host_os, you can't guess on the object format or if an OS > > honors LD_LIBRARY_PATH/LD_RUN_PATH or other advanced linker features > > libtool might require on a system (I am not a libtool expert, so bare > > with the examples). > > Libtool has however done exactly this with reasonable success for the > last 8 years... There are cases where testing $host is simply the path > of least resistance, but pragmatism is not a bad thing. Yes, libtool works, but by definition it is always behind. There are always new operating systems, and tools are always changing. That is why software I support has been using CVS versions of libtool since the very beginning. As a basis for comparison, there is a large population of developers still using a version of Autoconf which dates from 1996. Apparently feature testing does work for many/most areas. As far as shared library naming and linker features goes, I expect that tests could be written which observe what works and what doesn't. Maybe in an hour or so, a feature-based libtool would come up with the right answers. Most people don't have that long to wait. 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: Solaris and socket library
This is an Autoconf issue, not Automake. Adding the following line to your configure.ac file will likely resolve the problem: AC_SEARCH_LIBS([connect],[socket],[],[],[]) It should add -lsocket to LIBS if necessary. Bob On Fri, 16 Jan 2004, John Ling wrote: > I am running on Solaris and I was trying to compile an application that > used the libmysqlclient.a library. > > I encountered an error: > > Undefined first referenced > symbol in file > socket > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) > getpeername > /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) > setsockopt > /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) > getservbyname > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) > getsockopt > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) > shutdown > /usr/local/mysql4/lib/libmysqlclient.a(viosocket.o) > connect > /usr/local/mysql4/lib/libmysqlclient.a(libmysql.o) > ld: fatal: Symbol referencing errors. > > > Now the solution was to add a -lsocket to the linking options. > But, should this not be something that autoconf or automake suite of > tools detect and automatically handle for me? Do I need to manually add > this only when I run on Solaris? > > Now that I do need to handle this. Where is the best place to check the > OS environment variable to see if I need to set this as a variable > somewhere. I wanted to do something like: > > ifeq ($(OSTYPE),solaris) > export SOCKET = -lsocket > endif > > Do I do this in configure.in somehow or in Makefile.am? Is there a > better way anyone can suggest. I would think something like this is a > common problem to handle. > > Thanks, > John Ling > > > == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Calling other external Makefiles and outside Make systems
On Mon, 26 Jan 2004, Ralf Wildenhues wrote: > > > > I don't understand this. If a third-party package uses an > > auxiliary script, say install-sh, then that third-party package > > already contains install-sh and does not care about the parent's > > auxdir. Am I missing something? What kind of adaptation do you > > want to avoid passing AC_CONFIG_AUX_DIR? > > Oh, yes, you're right. braino, sorry. This one is not about > not changing the subpackage, but about saving space in the combined > package. After all, auxiliary scripts with the same name are supposed > to be identical, right? That would be a very poor assumption. Scripts with the same name may output different values. For example, an older config.guess script may output a different host tripplet for the same OS than a newer config.guess, and the version of tools used in the subdirectory key off this older host tripplet. They would misbehave if they were directed to use the newer config.guess. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Calling other external Makefiles and outside Make systems
On Tue, 27 Jan 2004, Ralf Wildenhues wrote:
>
> Ahh, thanks. Well that surely destroys this idea.
>
> But begs for another, config.guess related question:
> Its output being this unstable means: If you want to
> make good use of config.guess, you better be tracking it
> constantly. Ok, I knew this method would be useful to
> but a few packages (most notably libtool[1]), but this
> is a strong reassurance.
>
> Are there auxiliary scripts other than config.{sub,guess}
> which expose complexity rather than hiding it? Which?
These two are the main culprits. Usually when used in conjunction
with libtool. :-)
On the flipside, the config.guess output which is in flux is usually
related to new versions of systems that few people have even heard
about.
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: about requiring Perl 5.6 in Automake 1.9
On Mon, 9 Feb 2004, Akim Demaille wrote: > > > I'm considering dropping support for Perl 5.005 in the future > > Automake 1.9, and require at least Perl 5.6. Perl 5.6 will be 4 > > years old next month, so it does not sound like asking for the > > moon. > > Actually, why not jumping to something really more recent. Some > people will have to upgrade their Perl installation, so they probably > won't install 5.6 anyway. It is not trivial to upgrade many Perl installations. Doing so requires rebuilding Perl modules, and requalification to ensure that dependent software does not break. Perl 5.6.1 comes standard with many existing systems. Perl has worked fine since the beginning so I suggest that the minimum version be the minimum version that can be reasonably tested due to availability. 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/, 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, Karl Berry wrote: > I am against having separate install targets because GNU makefiles > normally install everything by default and that is what users should > > No, they don't currently install any Texinfo output format except Info. > And I don't see any particular reason why they should. Why install > HTML, when we're not installing XML, Docbook, PS, PDF, or > who-knows-what-else? What I mean is that 'make install' normally installs everything which is expected to be installed. > Installing everything is not a problem for distribution > maintainers since they decide which files to package using their > distribution tools. > > Not as far as GNU goes. If make install installs HTML, then they have > to provide HTML in the distribution .tar.gz -- exactly analogous to > Info. Otherwise, every *installer* has to have the right version of > makeinfo installed, which is not feasible. This is true/reasonable of the source packages (luckily HTML compresses very well), but there are often several "binary" installable packages offered for a given source package. The user can choose to install a package-doc or package-html install package if they want the extra documentation. The package maintainer decides what the best way is to slice/dice the files in a complete installation in order to offer end-users more freedom as to what occupies their disk space. The package maintainer is very likely to have the right Texinfo available for the job. If the HTML files are not distributed with the sources, then one way to deal with the situation is to have autoconf test for a recent enough texinfo package, and if it is too old, a warning is generated, and texinfo-based processing/targets are skipped. Keep in mind that texinfo is just one method among many (in addition to 'vi') for generating HTML documentation. Presuming that the GNU standards are extended to include HTML, if the user does 'make install' and the package provides HTML, it should be installed if at all possible. 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: html texinfo install?
On Tue, 17 Feb 2004, Karl Berry wrote: > > I can't imagine any method for autoconf to test for a "good enough" > Texinfo, since there's no way to specify exactly which Texinfo features > are (a) used in the source docs, or (b) implemented in the available > Texinfo. Couldn't the developer specify the minimum version of Texinfo which is required in order to handle the docs? If the developer doesn't have time to verify older versions, then he can just specify the version he used. Presumably Texinfo strives to be upward compatible with older versions. If not, then it is broken. This could be handled similar to the way Automake tests for a recent enough Python (i.e. via an Autoconf macro). Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: linking dlopenable modules together
This is due to a big problem that has not been solved yet. In some cases libtool needs to re-link the libraries at installation time. That means that any libraries a library depends on must already be installed. If a build system installs several libraries, then these libraries must be installed in the correct order or else problems will result. The only work-around is to carefully re-order the Makefiles and library build order so that the libraries happen to be installed in the correct order. As long as the LIBADDs are correct, Automake *does* have all the information that it needs in order to do the job (if it evaluates all Makefile.am's as a whole), but for a recursive build, each Makefile does not have all the information it needs. That means that either the 'automake' tool must somehow re-order the library install order if it can, or warn the developer that there is a problem. Currently it does nothing at all. For a non-recursive build, there is no reason why Automake can't accomplish the library install ordering on its own if all library dependencies are properly specified (it already does a great job of ordering the library build). Bob On Thu, 19 Feb 2004, Dale E Martin wrote: > I've got an automake/libtool build system. I'm building two modules, > Foo.la and Bar.la. I need to be able to dlopen them both in separate > systems. Foo.la has a dependency on Bar.la, and I'd like to link them > together so I do: > Foo_la_LIBADD = $(top_builddir)/Bar.la > > This appears to work OK when I do a "make", but when I do a "make install" > I get: > /usr/bin/ld: cannot find -lBar > collect2: ld returned 1 exit status > libtool: install: error: relink `Foo.la' with the above command before installing it > > Any ideas? I suppose I could make a convenience library that they both > depend on, is this the only way? > > Thanks, > Dale > -- > Dale E. Martin, Clifton Labs, Inc. > Senior Computer Engineer > [EMAIL PROTECTED] > http://www.cliftonlabs.com > pgp key available > > == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: AM_CPPFLAGS don't appear in cygwin CC line
On Fri, 20 Feb 2004, Alexandre Duret-Lutz wrote: > > Thomas> Are there known issues with cygwin, and automake-1.8.2? > > No reports yet. Does the test suite pass? GraphicsMagick builds fine under Cygwin. It uses Automake 1.8.2 with AM_CPPFLAGS. 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: How to handle documentation and move it in the right place.
On Wed, 25 Feb 2004, Hans Deragon wrote: >I am trying to jugle with automake and rpmbuild to get an RPM built with the > documentation in the proper place. I tried many things, but I never succeded to > get my documentation installed where I want. When the documentation is > installed in the right place using "make install", rpmbuild can't get the > documentation or complains. The most common procedure for building RPMs appears to be to do make DESTDIR=/somewhere install and then reference the installed files in /somewhere in the RPM spec file. This way the normal Automake install target is used and you don't need to worry about anything but 'install' in your Makefile.am files. 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: FEATURE REQUEST: make uninstall should delete empty directories.
On Fri, 5 Mar 2004, Frederik Fouvry wrote: > > ,-- On Wed, 3 Mar, Bob Friesenhahn wrote: > > [...] > > | 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. > > Won't remove commands refuse to clean up a directory if it's not > empty? The ANSI C remove() function removes non-empty directories under Linux. :-) On the other hand, the unlink() system call does not remove non-empty directories. Since Automake is multi-platform, it is wise to verify that all supported platforms can support safe directory removal semantics. Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [Fwd: Can nobase_pkgdata_DATA take directories? Does not seam so.]
On Fri, 5 Mar 2004, Hans Deragon wrote: > > Obviously, if you and I are building systems to emulate wildcards, its because > there is definitively a need for wildcards to be supported. Should we make a > feature request? Wildcards are for lazy programmers who are willing to allow wrong files to be built or distributed by accident. The existing Automake -hook targets provide package authors with considerable control over what gets distributed, installed, and uninstalled. Since they can execute arbitrary shell code, wildcards can be supported for any target which supports -hook. Using run-time Makefile includes is not portable. 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: Problems installing dependant libraries
On Mon, 15 Mar 2004, Fredrick Meunier wrote: > > Bob Friesenhahn wrote: > > 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. > > In my case it is a non-recursive build with _LIBADD entries for all the > inter-library dependencies, my problem boils down to installations being > done in the order specified in lib_LTLIBRARIES, even if _LIBADD entries > list dependencies that are violated by this ordering. As the entries for > these lists are autogenerated in my project, I would prefer not having > to hack the generators to mainain a particular order for the libraries > as this is neccesarily brittle. I totally agree that Automake has no reasonable excuse for not installing libraries in the correct order for non-recursive builds. It has all of the information it needs, and already generates the correct rules to build the libraries in the correct order. Since Automake is implemented in Perl, it has plenty of power at its disposal to compute the correct library installation order. 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 "dlopen"ing 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?
Under Solaris 9, neither GNU make or Solaris's make is able to deal with building automake 1.8.3 from the distribution archive: scooby: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 scooby:src/gnu/automake-1.8.3% make Making all in . doc m4 lib tests cd: no such file or directory: . doc m4 lib tests *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Automake 1.8.3 doesn't build?
I regenerated the Automake 1.8.3 Makefiles using Automake 1.8.2 and then I was able to configure and install Automake 1.8.3 under Solaris 9. I then regenerated the Automake 1.8.3 Makefiles using the just installed Automake 1.8.3 and was able to successfully configure, build, and install Automake 1.8.3. I suspect that there is something wrong with the Automake 1.8.3 tarball. Maybe there is a directory timestamp problem? 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: > > 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?
On Sun, 18 Apr 2004, Eric Sunshine wrote: > I can submit a patch to autoconf-patches to make Autoconf's shell selection > more backward-compatible with earlier versions of Autoconf, however this > raises another issue. My interpretation of this thread is that Autoconf's new > shell selection behavior is exposing a latent problem with Automake; > specifically, Automake-generated makefiles do not deal with zsh in a robust > fashion. Even after patching Autoconf, it will still be possible for zsh to > be the chosen shell (it just won't be as likely), so this same problem can > continue to affect Automake. Furthermore, it does not really seem like > Autoconf's responsibility to work around a shortcoming in Automake. After > all, Autoconf has long considered zsh an acceptable shell (otherwise, those > zsh work-arounds would not be present in Autoconf), so one might expect > Automake to also consider zsh a usable shell (by employing the same zsh goop, > for instance). I agree with your conclusions. Automake Makefiles should be more robust. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: SUBDIRS: can I make but not install?
You can use libtool's "convenience" library feature to support this. Automake and libtool work in conjunction to build a library which is not installed. Unfortunately, this likely requires replacing the 3rd party build environment. Since Automake also supports non-recursive builds, you can create a build environment for the 3rd party library in your own Makefile.am without disturbing the one that the 3rd party library normally uses. Bob On Sun, 18 Apr 2004, Gregory Sharp wrote: > > My program uses a 3rd party library, that I include with the > distribution as a subdirectory. > > I want to build the library, and statically link to it, which > works OK by including the subdirectory as SUBDIRS. But the > problem is that "make install" also wants to install the > library, which I don't need. Any suggestions for working > around this? I prefer not to modify the 3rd party autoconf/make > scripts. > > And a more meta-question, is there any good reference or > document about how one should include 3rd party libraries > in one's package? > > Thanks! > Greg > > > = > Greg Sharp > [EMAIL PROTECTED] > > > > > __ > Do you Yahoo!? > Yahoo! Photos: High-quality 4x6 digital prints for 25ยข > http://photos.yahoo.com/ph/print_splash > > == 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
Re: AutoGen-5.6.2 w/o libxml2 build problem
On Tue, 22 Jun 2004, Alexandre Duret-Lutz wrote: Hi Bruce! "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: [...] Bruce> When you invoke, "make dist" I believe you are claiming Bruce> that you wish to construct a new distribution for some Bruce> distribution-related purpose. If you merely wish to Bruce> verify that the parts that you can build are built Bruce> correctly, you would invoke, "make check". If you are Bruce> making a distribution, then that distribution needs to Bruce> be verified that all parts of it are functional. It Bruce> would be difficult to verify the functionality of ag2xml Bruce> if you do not have libxml2. Therefore, I do not think Bruce> it is correct to try to do a "make dist" when all Bruce> components cannot be built. [...] I tend to disagree. First, `make dist' is a *user* target and I'd expect it to work even when some part of the tree is not being built. For instance a user might have fixed the package locally, and will want to run `make dist' in order to carry his fixed version to other hosts. He may not care about the subpart of the package that isn't build. Second, there are cases where it is simply not possible to build all directories: setup with architecture-dependent directories come to mind. Hear! Hear! It is best/necessary to recurse all directories and use Automake conditionals to map out parts that shouldn't be built. For a properly maintained open source package using Automake, any user with appropriate standard tools (may need some GNU versions to fix bugs) should be able to extract the distribution to a directory, configure it, and then be able to successfully execute any target documented in the Automake manual. This should be a requirement for any GPLed or LGPLed package since failure to support this flexibilty is a failure to support the spirit of GPL and open source in general. Any recipient of the package should have the ability to become a package "maintainer" without removing site/developer specific hacks. 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
