Re: Testing python extension modules during 'make distcheck' / 'make check'
Hello Mark, * Mark Asbach wrote on Fri, Nov 03, 2006 at 12:31:41AM CET: > > I'm one of the maintainers of an open source image processing toolkit > (OpenCV) and responsible for parts of the autotools setup. The > package mainly consists of four shared libraries but is accompanied > by a python package containing some pure python code and of course > extension modules for the four libraries. OK. One idea with libtool-generated libraries is that the uninstalled libraries and programs that use them have RPATH (or similar) entries pointing to the locations within the build tree (so that 'make check' finds them and uses them). At 'make install' time, if need be, some relinking happens so that no more build tree references remain. I assume for python modules and stuff you need some similar functionality. I think one possibility to achieve this is to temporarily (i.e., by the 'make check' machinery) augment PYTHONPATH to also point to the uninstalled modules. There is a plan to eventually merge this with the libtool shell wrappers, but for now you should be able to set that in TESTS_ENVIRONMENT, like this or similar: TESTS = ... TESTS_ENVIRONMENT = PYTHONPATH="../python:$$PYTHONPATH" > I know that I could use the install-check target to just start my > python tests post installation of the libraries and the python > module. The question is, will install-check be invoked during 'make > distcheck' automatically? Yes, but it's spelled 'installcheck', and the extension rule is spelled 'installcheck-local'. If you write such a rule yourself, you could adjust it by some other means; in CVS Libtool, we use a variable INSTALLCHECK_ENVIRONMENT for this (but the name has no special meaning to Automake). > I couldn't find any information on how to > do that ... Also I would have to tell python and the operating system > where to find python modules and shared libraries (again) ... My goal > is to have everything checked during distcheck to really make sure I > don't hand out broken tarballs. Sure. I hope the above gets you there. If not, post what you have (or a link to a tarball) and we can see. Cheers, Ralf
Re: [automake]ltmain file not found
Run libtoolize to generate ltmain.sh On 11/3/06, Praveen M R <[EMAIL PROTECTED]> wrote: hi, I am getting following error. [EMAIL PROTECTED] one]$ automake --add-missing configure.ac:3: required file `./ltmain.sh' not found regards, Praveen
[automake]ltmain file not found
hi, I am getting following error. [EMAIL PROTECTED] one]$ automake --add-missing configure.ac:3: required file `./ltmain.sh' not found regards, Praveen
Re: [automake] Debian and its alternatives' system.
Benoit Perrot wrote: > On debian, several version of the same package may be installed, > and the default, prefered one is selected by providing a > symbolic link pointing to it. Yes. Very nice. > So, I was wondering if there was a way to select the automake > path or exe to use, or if patching AM_INIT_AUTOMAKE could be > the solution. You can always set PATH to $HOME/bin and in there make a symlink or wrapper script from 'automake' to 'automake-1.9' or whatever. Because it is in your PATH ahead of the /usr/bin/automake location it will be found first and used. Bob
Re: [automake]error in Makefile.am
If you write "bin_PROGRAMS = ../bin/helloinvite" then you must write "___bin_helloinvite_SOURCES = main.c say.c invite.c". On 11/3/06, Praveen M R <[EMAIL PROTECTED]> wrote: src/Makefile.am AM_CPPFLAGS = -I$(srcdir)/../include bin_PROGRAMS = ../bin/helloinvite helloinvite_SOURCES = main.c say.c invite.c helloinvite_LDADD = ../lib/libhelloinvite.la
Re: [automake]error in Makefile.am
The following ic Makefiles Makefile.am SUBDIRS = include lib bin src include/Makefile.am helloinvite_SOURCES = say.h invite.h src/Makefile.am AM_CPPFLAGS = -I$(srcdir)/../include bin_PROGRAMS = ../bin/helloinvite helloinvite_SOURCES = main.c say.c invite.c helloinvite_LDADD = ../lib/libhelloinvite.la ~ lib/Makefile.am lib_LTLIBRARIES = libhelloinvite.la libhelloinvite_la_SOURCES = ../src/say.c ../src/invite.c ../include/say.h ../include/invite.h bin/Makefile.am bin_PRAGRAMS = helloinvite Hi, I am getting following message when I enter automake --add-misssing I feel I am doing wrong in Makefile.am. Under main directory i have include src lib bin directories..In include directory I am placing *.h files and in lib directory .la should be created..and in bin directoty target should be created. In src directory i have kept 2 source (.c) files... I want Makefile.am file to be written to include directory,bin and lib directory...I knew the below program i am facing because of wrong Makefile.am file. Kindly help ma regarding this. regards, Praveen [EMAIL PROTECTED] databltz]$ automake --add-missing src/Makefile.am:4: variable `helloinvite_LDADD' is defined but no program or src/Makefile.am:4: library has `helloinvite' as canonic name (possible typo) src/Makefile.am:3: variable `helloinvite_SOURCES' is defined but no program or src/Makefile.am:3: library has `helloinvite' as canonic name (possible typo) configure.ac:3: required file `./ltmain.sh' not found Mike Frysinger wrote: On Thursday 02 November 2006 23:51, Praveen M R wrote: I am getting following message when I enter automake --add-misssing I feel I am doing wrong in Makefile.am. we can only guess at what you're doing wrong unless you actually post the Makefile.am -mike
Re: [automake]error in Makefile.am
On Thursday 02 November 2006 23:51, Praveen M R wrote: > I am getting following message when I enter automake --add-misssing > I feel I am doing wrong in Makefile.am. we can only guess at what you're doing wrong unless you actually post the Makefile.am -mike pgp73JtHwWvJP.pgp Description: PGP signature
[automake]error in Makefile.am
Hi, I am getting following message when I enter automake --add-misssing I feel I am doing wrong in Makefile.am. Under main directory i have include src lib bin directories..In include directory I am placing *.h files and in lib directory .la should be created..and in bin directoty target should be created. In src directory i have kept 2 source (.c) files... I want Makefile.am file to be written to include directory,bin and lib directory...I knew the below program i am facing because of wrong Makefile.am file. Kindly help ma regarding this. regards, Praveen [EMAIL PROTECTED] databltz]$ automake --add-missing src/Makefile.am:4: variable `helloinvite_LDADD' is defined but no program or src/Makefile.am:4: library has `helloinvite' as canonic name (possible typo) src/Makefile.am:3: variable `helloinvite_SOURCES' is defined but no program or src/Makefile.am:3: library has `helloinvite' as canonic name (possible typo) configure.ac:3: required file `./ltmain.sh' not found
[automake]error in Makefile.am
Hi, I am getting following message when I enter automake --add-misssing I feel I am doing wrong in Makefile.am. Under main directory i have include src lib bin directories..In include directory I am placing *.h files and in lib directory .la should be created..and in bin directoty target should be created. In src directory i have kept 2 source (.c) files... I want Makefile.am file to be written to include directory,bin and lib directory...I knew the below program i am facing because of wrong Makefile.am file. Kindly help ma regarding this. regards, Praveen [EMAIL PROTECTED] databltz]$ automake --add-missing src/Makefile.am:4: variable `helloinvite_LDADD' is defined but no program or src/Makefile.am:4: library has `helloinvite' as canonic name (possible typo) src/Makefile.am:3: variable `helloinvite_SOURCES' is defined but no program or src/Makefile.am:3: library has `helloinvite' as canonic name (possible typo) configure.ac:3: required file `./ltmain.sh' not found
Testing python extension modules during 'make distcheck' / 'make check'
Hi automake developers, I'm one of the maintainers of an open source image processing toolkit (OpenCV) and responsible for parts of the autotools setup. The package mainly consists of four shared libraries but is accompanied by a python package containing some pure python code and of course extension modules for the four libraries. Now during the last month we were preparing a major release which means testing, fixing, testing, fixing, ... in the first degree. Typical functionality of the shared libraries is verified during 'make check' and 'make distcheck' by binaries that are linked against the libraries (straight forward) and are listed in the 'TESTS' automake primary. Unfortunately, many problems with the python wrappers were overseen from time to time. Currently we have to build and install before we can run any python-based test routines. When trying to integrate python module testing into the automake setup, there are some problems that I couldn't find a solution for: a) the extension modules are built in different (other) subdirectories - so they are not in the local path where python could find them b) the libraries and extension modules are built with libtool and may have rpaths compiled in (is this problematic)? c) a different version of our wrappers might be installed on the testing machine, somewhere in python/site-packages. How can I make sure that python only finds my 'new' local generated modules? I know that I could use the install-check target to just start my python tests post installation of the libraries and the python module. The question is, will install-check be invoked during 'make distcheck' automatically? I couldn't find any information on how to do that ... Also I would have to tell python and the operating system where to find python modules and shared libraries (again) ... My goal is to have everything checked during distcheck to really make sure I don't hand out broken tarballs. Did someone solve a similar problem? Thanks in advance, Mark P.S.: I'll post a similar message to the python mailing list, but last time I asked an autotools/python related questions, there were not many answers ... -- Dipl.-Ing. Mark Asbach Tel +49 (0)241 80-27677 Institute of Communications Engineering Fax +49 (0)241 80-22196 RWTH Aachen University, Germany http://www.ient.rwth-aachen.de
Re: [automake] Debian and its alternatives' system.
Hi, Benoit Perrot wrote: > As `automake' (ie automake-1.7) is searched, autoconf fails. Just call it explicitly once, the resulting Makefile.in will contain the proper name for eventual updates then; i.e. aclocal-1.9 autoheader automake-1.9 autoconf At least that works for me. :-) Simon
Re: [automake] Debian and its alternatives' system.
* Benoit Perrot ([EMAIL PROTECTED]) wrote: > Hello, > > I am facing an issue with the AM_INIT_AUTOMAKE macro -- I don't know > if it is more an autoconf or an automake problem. > > On debian, several version of the same package may be installed, > and the default, prefered one is selected by providing a > symbolic link pointing to it. > > Let's imagine I have automake-1.7 and automake-1.9 on my system, > and the `automake' symbolicaly links to automake-1.7. > The `configure.ac' of my project contains the statement: > > AM_INIT_AUTOMAKE([1.9]) > > As `automake' (ie automake-1.7) is searched, autoconf fails. > What is sad is that automake-1.9 _is_ present on my system, > it is simply not the default one. Of course, I could use the > update-alternatives utility of debian to modify it, but for > this I need root access to the system. > > So, I was wondering if there was a way to select the automake > path or exe to use, or if patching AM_INIT_AUTOMAKE could be > the solution. > > What do you think? Since now by default the "automake" symlink will automatically point to the latest version of automake installed on the system. So that situation when the administrator has explicitly set the alternative to something else, and should probably live with the consequences. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
[automake] Debian and its alternatives' system.
Hello, I am facing an issue with the AM_INIT_AUTOMAKE macro -- I don't know if it is more an autoconf or an automake problem. On debian, several version of the same package may be installed, and the default, prefered one is selected by providing a symbolic link pointing to it. Let's imagine I have automake-1.7 and automake-1.9 on my system, and the `automake' symbolicaly links to automake-1.7. The `configure.ac' of my project contains the statement: AM_INIT_AUTOMAKE([1.9]) As `automake' (ie automake-1.7) is searched, autoconf fails. What is sad is that automake-1.9 _is_ present on my system, it is simply not the default one. Of course, I could use the update-alternatives utility of debian to modify it, but for this I need root access to the system. So, I was wondering if there was a way to select the automake path or exe to use, or if patching AM_INIT_AUTOMAKE could be the solution. What do you think? Best reagrds, -- Benoit Perrot
