Re: utility programs used during build
On Tuesday, January 13, 2004, at 06:05 pm, Warren Turkal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 13 January 2004 05:54 am, Gary V. Vaughan wrote: Warren Turkal wrote: | Is there any analysis on what it would take to create utility programs | that are only used during build in a crosscompiled environment in | automake? | | I and working on the libX11 for Freedesktop.org and it builds a file and | uses it during installation, but does not install it. I am under the | impression that automake does not support this right now. What would be | needed to add support for this feature. Does this work? nodist_PROGRAMS = installtool install: installtool I don't undersand what your example does. Isn't nodist implied on PROGRAMS? Yes it is, I meant noinst_, but my fingers typed nodist_ :-/ The following example is closest I can come up with. It will not work if you are cross compiling. noinst_PROGRAMS = installtool That's what I meant. installtool_SOURCES = installtool.c This is implied. If no sources are given, $PROGRAMNAME.c is used by default. It will attempt build a host targetted binary. That binary will not run on the build system. This is why I think automake needs to be extended. It depends on the compiler you use. If you have configured with a crosscompiler, it will do that yes. Maybe you can override it? You would have to copy the compile and link rules from the generated Makefile into your Makefile.am, and then change the compiler to $(CC_BUILD) or something... I didn't see your other message until after I answered this one. You are right that it would be nicer if Automake had built in support for such things. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://www.oranda.demon.co.uk GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
Re: utility programs used during build
Gary V.Vaughan wrote: It depends on the compiler you use. If you have configured with a crosscompiler, it will do that yes. Maybe you can override it? You would have to copy the compile and link rules from the generated Makefile into your Makefile.am, and then change the compiler to $(CC_BUILD) or something... I didn't see your other message until after I answered this one. You are right that it would be nicer if Automake had built in support for such things. This is where I am intending to go. BTW, what do I need to do to get copywrite assignment paperwork done so that my hopeful changes can be incorporated without issue. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org
Re: 1.8 and mkdir_p
Bob Friesenhahn wrote: 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. Agreed. That's a use of the distribution name and version that won't cause a lot of problem to someone who creates a new distribution. It is way to late to even think about changing things now. Well, you can create and maintain a 'config.linuxdistro' on your own... Bruno
Re: make distcheck problem
Lars == Lars Hecking [EMAIL PROTECTED] writes: Lars if BUILD_SRC_BEOS_SUBDIR Lars d_beos = beos Lars endif Lars SUBDIRS = $(d_beos) Lars If I run make distcheck in the top level directory, it bombs out at Lars one point because the beos subdir doesn't exist. Is this a bug in Lars automake? Is there any way to work around it? I am not running on Use `DIST_SUBDIRS'. Tom
Re: 1.8 and mkdir_p
It is way to late to even think about changing things now. It's never too late to improve software. The amount of software that will be created from here on can be reasonably expected to be MUCH greater than what has been written so far. The change to, for example: i686-DistroRev-linux-gnu should be pretty painless as far as that goes. Certainly not as painful as going from the 3 to 4 part form when the linux-gnu form was introduced. Well, you can create and maintain a 'config.linuxdistro' on your own... Yes, and then code: ... cvo=`config.guess` case $cvo in *-*-linux-gnu) cvo=`config.linuxdistro` ;; esac ... everywhere one would otherwise simply code: cvo=`config.guess` H
Re: Internal Error
Patrick == Patrick Welche [EMAIL PROTECTED] writes: Patrick Slowly giving up.. autoconf cvs with Eric Sunshine's Patrick SHELL patch applied, but maybe not propagated to all Patrick the executables involved, and automake cvs of today, Patrick NetBSD-1.6ZG/i386, in the automake directory: Patrick % sh bootstrap Patrick Found no shell that has working shell functions. Patrick Please tell [EMAIL PROTECTED] about your system. From your mail to autoconf-patches, I'm assuming this is fixed. Is this correct? -- Alexandre Duret-Lutz
Re: Internal Error
On Wed, Jan 14, 2004 at 06:28:55PM +0100, Alexandre Duret-Lutz wrote: Patrick == Patrick Welche [EMAIL PROTECTED] writes: Patrick Slowly giving up.. autoconf cvs with Eric Sunshine's Patrick SHELL patch applied, but maybe not propagated to all Patrick the executables involved, and automake cvs of today, Patrick NetBSD-1.6ZG/i386, in the automake directory: Patrick % sh bootstrap Patrick Found no shell that has working shell functions. Patrick Please tell [EMAIL PROTECTED] about your system. From your mail to autoconf-patches, I'm assuming this is fixed. Is this correct? Yes - all well with autoconf 2.59. Cheers, Patrick
Re: Odd warning
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf Hi, Ralf After having upgraded from automake-1.8.1 to automake-1.8.2 (And having Ralf modified some Makefile.ams), I received this warning from automake: Ralf configure.ac:16: version mismatch. This is Automake 1.8.2, Ralf configure.ac:16: but the definition used by this AM_INIT_AUTOMAKE Ralf configure.ac:16: comes from Automake 1.8.1. You should recreate Ralf configure.ac:16: aclocal.m4 with aclocal and run automake again. Ralf WARNING: `automake-1.8' is probably too old. You should only need it if Ralf you modified `Makefile.am', `acinclude.m4' or `configure.ac'. Ralf You might want to install the `Automake' and `Perl' packages. Ralf Grab them from any GNU archive site. Ralf cd . /bin/sh ./config.status Makefile Ralf I don't understand why this warning is issued. Ralf To my understanding automake-1.8.1 and automake-1.8.2 both should Ralf implement the automake-1.8 API and therefore should be sufficiently Ralf compatible. It's the `Automake API', not the `automake API'. I.e., the API applies to the package, not to the individual command. For instance generated Makefile rules can rely on internal configure substitutions defined by M4 macros, and this interaction is not covered by the API. How about adding the appended section to the manual? Ralf Therefore, I don't understand why Ralf 1. this warning is required at all. Ralf 2. automake doesn't automatically try to do what it recommends the user Ralf to do manually: running aclocal and automake. That makes sense to me, but this looks a bit complicated to implement, and (I feel) more error prone that the current situation. One problem is that aclocal needs to be passed ACLOCAL_AMFLAGS, which 1) is not know in all directories 2) is not available at the time the warning is issued Another problem is that if automake was called to regenerate one Makefile.in, and consequently aclocal is run to update aclocal.m4, then all other Makefile.ins should be regenerated (the automatic rebuild rules will probably take care of that, but not every body use them). Upgrading a Package to a Newer Automake Version *** Automake maintains three kind of files in a package. * `aclocal.m4' * `Makefile.in's * auxiliary tools like `install-sh' or `py-compile' `aclocal.m4' is generated by `aclocal' and contains some Automake-supplied M4 macros. Auxiliary tools are installed by `automake --add-missing' when needed. `Makefile.in's are built from `Makefile.am' by `automake', and rely on the definitions of the M4 macros put in `aclocal.m4' as well as the behavior of the auxiliary tools installed. Because all these files are closely related, it is important to regenerate all of them when upgrading to a newer Automake release. The usual way to do that is aclocal # with any option needed (such a -I m4) autoconf automake --add-missing --force-missing or more conveniently: autoreconf -vfi The use of `--force-missing' ensures that auxiliary tools will be overridden by new versions (*note Invoking Automake::). It is important to regenerate all these files each time Automake is upgraded, even between bug fixes releases. For instance it is not unusual for a bug fix to involve changes to both the rules generated in `Makefile.in' and the supporting M4 macros copied to `aclocal.m4'. Presently `automake' is able to diagnose situations where `aclocal.m4' has been generated with another version of `aclocal'. However it never checks whether auxiliary scripts are up-to-date. In other words, `automake' will tell you when `aclocal' needs to be rerun, but it will never diagnose a missing `--force-missing'. Before upgrading to a new major release, it is a good idea to read the file `NEWS'. This file lists all changes between releases: new features, obsolete constructs, known incompatibilities, and workarounds. -- Alexandre Duret-Lutz
Re: 1.8 and mkdir_p
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. If for use at runtime then config.guess is very poorly suited. Do you really want to run the compiler at every run? It is a little slow. On some systems it runs the assembler. Oh, well, config.guess isn't designed for that -- it's for compile time decisions. In relation to my above comment, clearly for compile time decisions running the compiler makes a lot of sense. You are clearly joking! I am not saying that I want to run config.guess as part of every shell RC file. I am saying the information that *should* be returned by config.guess (in its original spec) are sometimes needed for runtime decisions in a variety of places. Uh, how does a runtime program obtain the information that *should* be returned by config.guess without actually running config.guess? uname -s, test -x /bin/rpm, test -x /bin/dpkg are probably what you're after. Not at all. I have a heterogeneous environment and I use runtime tests such as 'test -f /some/file' often. I also use 'somecommand --someoption' and check the return code often. It works very well. This style of coding is a single source style which works on different operating systems without resorting to trying to enumerate all possible configurations of them. I am talking about problems that you apparently have never had to really solve. Hmm... I have a large number (is 2000 machines of different types large?) of machines in my lab. I am willing to guess that I have had to deal with many of the problems which you are about to propose as examples which cannot be solved without using a lookup table. Perhaps I or others can suggest working alternatives to doing a table lookup for your problems as well? But this is clearly getting offtopic for automake. This would be more appropriate for the infrastructures[1] mailing list. Bob [1] http://mailman.terraluna.org/pipermail/infrastructures/
