Re: Automake with Python scripts
Hello, On Sun, Jul 30, 2006 at 02:24:52AM +0530, Debarshi 'Rishi' Ray wrote: > With this set-up 'make install' throws: > make[2]: *** No rule to make target `xmlrpclibauth.py', needed by > `install-pyexecPYTHON'. Stop. > make[2]: Leaving directory `/devel/GNOWSYS/g7/gnow/src' I really cannot understand how make can print this error if the file `xmlrpclibauth.py' is present in /devel/GNOWSYS/g7/gnow/src BTW, which version of Automake are you using? 1.9.6 is the latest one. More comments: > bin_SCRIPTS = gnow if this is a python script, you should perhaps use bin_PYTHON = gnow If you want to make compiled version of the script, Automake needs the filename with extension *.py. If that it a problem, you can create a wrapper or a symlink. If you want to use the SCRIPTS primary, dist_bin_SCRIPTS would be better. > configure.ac> > AM_INIT_AUTOMAKE([-Wall]) This line should go just after AC_INIT, at least before any other AM_* macro calls. > AC_CHECK_PROG([found],[python],[yes],[no]) Why do you need this? Try deleting it. > AC_OUTPUT([Makefile doc/Makefile src/Makefile]) This is an absolete form, use: AC_CONFIG_FILES([Makefile doc/Makefile src/Makefile]) AC_OUTPUT > Makefile.am > > EXTRA_DIST = AUTHORS ChangeLog COPYING INSTALL NEWS README This is not necessary, these files are distributed automatically. > MAINTAINERCLEANFILES = Makefile.in configure > > src/Makefile.am > > MAINTAINERCLEANFILES = Makefile.in The standard target `maintainer-clean' should leave the tree in a state where `configure&&make' is still possible. If you need a return-to-clean-cvs-checkout type target, you should rather use another name. > Using 'pyexecdir_PYTHON' in src/Makefile.am leads to an error while Indeed, `foo_PRIMARY' is coupled with `foodir', and `pyexecdir' is defined by AM_PATH_PYTHON, while `pyexecdirdir' is a nonsense. HTH, Stepan Kasal
Re: convenience libraries & binary size
On Tuesday 01 August 2006 15:26, Andreas Schwab wrote: > Pieter Grimmerink <[EMAIL PROTECTED]> writes: > > 1. move all >200 sourcefiles back into a single directory... > > 2. stop using autotools, so we no longer need convenience libs to > > handle subdirectories > > You don't need convenience libraries to handle subdirectories. Have you > tried subdir-objects? (*Note (automake)Options::.) Thanks, that saves me a bit of binary size. And, more importantly, this pointed me into the right direction; turned out most of the sudden binary size increase was because my -fno-exceptions CPPFLAG was not correctly passed to the convenience libraries, so all is fine again after I fixed that. With the correct flags, the actual difference between subdir-objects and convenience libraries turned out to be only only a few K's binary size, but still, since it's for a small system, I'm using subdir-objects now. Thanks again. Regards, Pieter
Re: convenience libraries & binary size
Is the *file* size bigger or are the results of 'size progname' bigger? h
Re: convenience libraries & binary size
On Wednesday 02 August 2006 20:18, Harlan Stenn wrote: > Is the *file* size bigger or are the results of 'size progname' bigger? I've just compared the size of the binary, I didn't use the 'size' command. Regards, Pieter
need to install (but not build or distribute) something to the bin directory...
Howdy all! I have just managed to get my library to build with mingw and produce windows DLLs. Yipee! Part of the process called for me to add a flag to the LD_FLAGS which causes gcc to produce an extra output file, called libnetcdf.def. This extra file is not a binary, but I want to install it in the same directory as the binaries. (Because that's where the DLL is getting installed, and I want the .def file to be installed with it.) Since the .def file is a byproduct of my linking, there is no command to build it, and it is not in the distribution. So how do I tell automake that there is a file I would like installed, but not specially built nor included in the distribution? I'm sure there is something very easy I am missing here... Thanks! Ed -- Ed Hartnett -- [EMAIL PROTECTED]