Re: redirecting produced files
Hi, I'm by no means an autotools expert, but there's a simple way to achieve something somewhat similar to what you want. You could run 'autoreconf -fvi' in your source directory, and then, depending on your arch/configuration, you can type: cd ../../bin/[os]/[compiler]/[debug/release] source_dir/configure debug/release and other options However, that would put both objects, libraries and binaries under the build directory (replicating the structure of your source directory). You can always have your toplevel Makefile.am put the resulting binaries in a bin directory, so then you could have: ../../[os]/[compiler]/[debug/release] as build directory ../../[os]/[compiler]/[debug/release]/bin for binaries ../../[os]/[compiler]/[debug/release]/src for objects, if src is where your sources are. I'm using something similar (one OS though, but different sets of configure options), based on an older post on this list by Ralf Wildenhues. Stefan. On 8/26/06, Isajha [EMAIL PROTECTED] wrote: For this question i produced little example program without I got the following automake (and autoconf) code - the real code is made up of several static and dynamic libraries as well as several executables. If you got a solution for me that might cause problems with debugging, linking, clean-up or anything else please mention it. I try to produce a non recursive makefile but im stuck already at the very beginning. Here the test program: Makefile.am bin_PROGRAMS = helloworldlinux client helloworldlinux_SOURCES = ../../src/helloworldlinux/HelloWorldLinux.cpp client_SOURCES = ../../src/client/MainLinux.cpp configure in. AC_INIT(test,0.1) AM_INIT_AUTOMAKE AC_PROG_CXX AC_PROG_INSTALL AC_OUTPUT(Makefile) The directory layout seems ok the file gets compiled and is linked - no errors. My problem is that the resulting executable (helloworldlinux in small letters) as well as the generated HelloWorldLinux.o (with capital letters) is located in the folder where the make file is. I do not want these files within the source directory nor in the directy of the makefile - the executable should be in ../../bin/[os]/[compiler]/[debug/release] (an eventually produced static library in ../../lib/[os]/[compiler]/[debug/release]) and the intermediate files in ../../obj/[os]/[compiler]/[debug/release]) Now im stuck since 5 days and i just don't find any solution. I'd love to know how just to set the output directory and then perhaps the best way to accomplish the [os]/[compiler]/[debug/release] and so on. Perhaps im googling for the wrong terms and therefore can't find anything. Any help would be very welcome. Thanks in advance.
Re: redirecting produced files
Hello Isajha, Stefan, * Stefan Puiu wrote on Mon, Aug 28, 2006 at 09:12:02AM CEST: On 8/26/06, Isajha [EMAIL PROTECTED] wrote: Makefile.am bin_PROGRAMS = helloworldlinux client helloworldlinux_SOURCES = ../../src/helloworldlinux/HelloWorldLinux.cpp client_SOURCES = ../../src/client/MainLinux.cpp This looks very suspicious. You should have the Makefile.am file in the same directory (or directory tree) as the source files. So something like bin_PROGRAMS = helloworldlinux client helloworldlinux_SOURCES = helloworldlinux/HelloWorldLinux.cpp client_SOURCES = client/MainLinux.cpp would look much better. And create the configure.ac file in that same directory, too. I do not want these files within the source directory nor in the directy of the makefile - the executable should be in Please get familiar with the GNU build concept of three different directory trees: the source tree (the one where all the files are which you write manually; usually at the top directory there is a configure.ac file, and this tree has one or more Makefile.am files). Tools like autoconf, automake, or autoreconf are run within this source tree. Then the build tree: that's a (possibly) different tree _from where_ you execute the configure script. This tree will hold for example all Makefiles, and all files created by a compiler: object files, libraries, programs. You can have several build trees for one project at the same time. Then the install tree: where programs and libraries (and possibly more) will be copied to by make install The paths for the install tree are chosen by arguments to `configure', for example --prefix, or --bindir. By default, installed files will live below /usr/local. Once you've grasped this concept, choose whether this: ../../bin/[os]/[compiler]/[debug/release] should be a build tree or an install tree; it sounds like you want the former. The next Automake release will have an introductory chapter covering this better than the current documentation does; but still, it has all the gory details. And there's a nice tutorial: http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html Cheers, Ralf
Re: redirecting produced files
I == Isajha [EMAIL PROTECTED] writes: [...] I Now im stuck since 5 days and i just don't find any solution. Don't waste your time: that's not how the GNU Build System is supposed to work. See http://news.gmane.org/find-root.php?message_id=%3c2006%2d08%2d12%2d23%2d45%2d50%2b6381%2badl%40gnu.org%3e especially section 2.2.6 about VPATH builds. [...] -- Alexandre Duret-Lutz Shared books are happy books. http://www.bookcrossing.com/friend/gadl
Re: distdir unset in subdir Makefiles?
DF == David Fang [EMAIL PROTECTED] writes: DF Hi, DF I've noticed that the distdir variable in generated Makefile.in's DF only appears in the top-level Makefile.in, however, it is not set in DF subdirectories' Makefile.in's. Is this intentional? Yes. When packages are nested the subpackage doesn't know the distdir value, it has to be passed by the parent. -- Alexandre Duret-Lutz Shared books are happy books. http://www.bookcrossing.com/friend/gadl
Re: redirecting produced files
Isajha, Please do not start a new thread when replying to a message. Please answer to that message by hitting the 'reply' (or similar) button, so that threading is not needlessly destroyed. * Isajha wrote on Mon, Aug 28, 2006 at 10:37:21AM CEST: I forgot to mention that for this project it is not allowed to have any build system specific files in the source directories. As for different operating systems different compilers/build environments/ide's are used we can not afford to use any toolset that requires to clutter our source directories with it's proprietary files. The Autotools are not proprietary. And no, I don't think all of your requirements can be reasonably met without extreme bending over. Some packages have tried this again and again, but IMHO it's not worth the pain. What does automake at. It writes all *.o files of for example project_1 to project_n IN the autotools folder as the Makefile.am is in there. If you would read what Alexandre and I wrote, you would know how to solve this particular issue. Cheers, Ralf
Re: distdir unset in subdir Makefiles?
Hello Alexandre, On Mon, Aug 28, 2006 at 10:04:09AM +0200, Alexandre Duret-Lutz wrote: DF == David Fang [EMAIL PROTECTED] writes: DF I've noticed that the distdir variable in generated Makefile.in's DF only appears in the top-level Makefile.in, however, it is not set in DF subdirectories' Makefile.in's. Is this intentional? Yes. When packages are nested the subpackage doesn't know the distdir value, it has to be passed by the parent. I'm afraid your answer does not answer the David's question. Let me quote the second paragraph: DF In one instance, I wished to manually inspect the result of one of DF the subdirectories' make distdir, but had to pass in these two variables DF by hand, slightly inconvenient. Is there a rationale for omitting these DF two variables in subdir's Makefile.in's? The suggestion is that one might occassionally need to do `make distdir' in a subdirectory of a project. (No subpackages are involved.) My answer was that the advantage of shortening each makefile by two lines is bigger than the discomfort reported, because the need for non-top `make distdir' is very rare. (But I was not sure whether this is the right answer, so I decided to wait for a better answer from someone else.) Stepan Kasal
Re: automake-1.9.6 make check failed on Solaris 8
Hello Frank, * Frank Middleton wrote on Sat, Aug 26, 2006 at 04:34:21PM CEST: Trying to install GCC 4.1.1; the instructions said to install automake versions 1.9.3. 1.9.6 is the most recent stable release (and features only bugfixes over 1.9.3), so that would be the one recommended to use. The most recent gcc Sparc binary I could find was 3.4.2. The problem I am trying to solve is with R *** caught bus error *** address 5, cause 'invalid alignment'. That can be anything from a compiler or assembler bug to a programming error in R. Is this an automake problem? Building guile-1.8.0 (required for gcc 4.1.1) sh ./configure . checking for __gmpz_init in -lgmp... no configure: error: GNU MP not found, see README # nm /usr/local/lib/libgmp.so | grep __gmpz_init [897] | 88736| 64|FUNC |GLOB |0|13 |__gmpz_init No. To find out who is at fault here, look at the part of config.log that deals with this test. It usually provides clues as to what is going wrong here. Here's the make check output. If there's anything else you need or if there are any other tests you'd like to run please let me know - only too happy to help... 2 of 517 tests failed uname -a SunOS apogee2 5.8 Generic_108528-18 sun4u sparc SUNW,Ultra-5_10 Solaris gcc --version gcc (GCC) 3.4.2 Please do a cd tests VERBOSE=x TESTS=ltconv.test subobj9.test make -e check and send the output, so we can see whether these bugs have since been fixed or whether they are unknown. Thanks, Ralf
Re: redirecting produced files
Sry about the double post. I am using www.nabble.com now to access the mailing list with a more forum like and convenient interface. -- View this message in context: http://www.nabble.com/redirecting-produced-files-tf2175986.html#a6017330 Sent from the Gnu - Automake - General forum at Nabble.com.
Re: distdir unset in subdir Makefiles?
DF In one instance, I wished to manually inspect the result of one of DF the subdirectories' make distdir, but had to pass in these two variables DF by hand, slightly inconvenient. Is there a rationale for omitting these DF two variables in subdir's Makefile.in's? The suggestion is that one might occassionally need to do `make distdir' in a subdirectory of a project. (No subpackages are involved.) My answer was that the advantage of shortening each makefile by two lines is bigger than the discomfort reported, because the need for non-top `make distdir' is very rare. (But I was not sure whether this is the right answer, so I decided to wait for a better answer from someone else.) Hi, Well, in any case, it's not too difficult for me to add my own target, say 'distdir-subdir' and pass the $(PACKAGE)-$(VERSION)[/$(subdir)] paths in that way, calling make recursively. I have a global Makefile.include that is include-inlined into every Makefile.in by automake for various useful variable definitions and phony targets. David Fang Computer Systems Laboratory Electrical Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!)
trying to install docs that are distributed with my package...
Howdy all!
I have some documentation which accompanies my library. I would like
to install the documentation on the user machine, without building it
on the user machine.
What I want is to build the documentation on the developer's machine,
include it in the distribution, and then install it.
The documents are all texinfo documents, and we cannot require that
every user machine have texinfo and tex installed.
For example, I can build my manuals, and include their postscript,
PDF, info, and ASCII text versions in the distribution like this:
# These are the source files for all the netcdf manuals.
info_TEXINFOS = netcdf.texi netcdf-install.texi netcdf-c.texi \
netcdf-f77.texi netcdf-f90.texi netcdf-cxx.texi netcdf-tutorial.texi
# Get lists of the corresponding ps, info, and pdf files.
ps_docs = ${info_TEXINFOS:.texi=.ps}
pdf_docs = ${info_TEXINFOS:.texi=.pdf}
info_docs= ${info_TEXINFOS:.texi=.info}
txt_docs= ${info_TEXINFOS:.texi=.txt}
# These files will be included with the dist.
EXTRA_DIST = $(ps_docs) $(pdf_docs) $(txt_docs) $(info_docs)
This works well. The documents are all build on the developer machine
when make dist is run, and they all appear in the distribution as
built documentation. When I run make all on the distribution,
nothing happens with these documents. (I am using no-installinfo as an
automake option).
This is exactly what I want.
But how to get automake to install them?
I tried this:
docdir = $(prefix)/doc/$(PACKAGE)-$(VERSION)
doc_DATA = $(ps_docs) $(pdf_docs) $(txt_docs) $(info_docs)
But this now causes the postscript, PDF, text, and info files to be
built when I run make install on the distribution. In other words,
it doesn't try to install the files I've already included in the
distribution, it rebuilds them all. I don't want it to rebuild the
files, just to install the ones I've already shipped.
Any thoughts on this?
Thanks!
Ed
--
Ed Hartnett -- [EMAIL PROTECTED]
Re: trying to install docs that are distributed with my package...
Ed Hartnett [EMAIL PROTECTED] wrote: What I want is to build the documentation on the developer's machine, include it in the distribution, and then install it. The documents are all texinfo documents, and we cannot require that every user machine have texinfo and tex installed. It sounds like the best plan would be to add a flag to configure that indicates you want to build docs, like --with-build-docs using AC_ARG_WITH. Then you could use the AM_CONDITIONAL macro to set it up to be an automake conditional, and use if directives in your Makefile.am to make it so that the rules for building documentation only appear when that flag is specified. There's plenty of documentation on this (just look up AM_CONDITIONAL). If you want an example, I do this all over the place for stuff in mod_bt [http://www.crackerjack.net/mod_bt/]. Cheers, Tyler
