Re: Is including a custom dist-foo into distcheck impossible
I do something similar for building an nsis-based win32 installer: http://pidgin-bs.svn.sourceforge.net/viewvc/pidgin-bs/bot-sentry/trunk/configure.ac?revision=165&view=markup http://pidgin-bs.svn.sourceforge.net/viewvc/pidgin-bs/bot-sentry/trunk/Makefile.am?revision=165&view=markup Note that these are conditional targets, since I want the package to build/distcheck even on hosts that don't have makensis installed and available. I don't know that my way is 'correct' and although it appears to work, I'm open to any improvements that may be noticed. Also, you may wish to reconsider whether it is wise to include a debian target/directory directly, or whether you might follow the usual convention for delivering debian source packages: http://lists.alioth.debian.org/pipermail/pkg-request-tracker-maintainers/2006-October/000175.html http://osdir.com/ml/linux.debian.devel.mentors/2002-11/msg00143.html http://people.debian.org/~mpalmer/debian-mentors_FAQ.html ([EMAIL PROTECTED] is a good place for further discussion) On 6/7/07, Noah Slater <[EMAIL PROTECTED]> wrote: Hello, I am developing a package with Automake that needs to have a custom dist taget for making debian packages in addition to the usual tarballs etc. I have created a dist-deb that works perfectly but I am unable to find any way of including this into the distcheck target. Is this possible? Thanks, Noah -- "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman -- ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html
Re: make distcheck and the /etc dir
On 6/4/07, deckrider <[EMAIL PROTECTED]> wrote:
On 6/4/07, Jason Curl <[EMAIL PROTECTED]> wrote:
> Daniel Leidert wrote:
> > BTW: If you use
> >
> > etcdir=${sysconfdir}
> >
> > you can set
> >
> > DISTCHECK_CONFIGURE_FLAGS = --sysconfdir=/etc
> >
> > And if you want to make this the default, set it in your configure
> > script:
> >
> > AC_SUBST([sysconfdir],[/etc])
> >
> > However, you should carefully think about this. I personally would leave
> > it up to the user to choose a directory.
>
> After comments from previous posts I'm thinking how I can then take the
> prefix the user provided and put that in "config.h" that the program can
> then read to know where the configuration files are. I'll now have to
> learn how to extend the installation to make backups of any old
> configurations that might be there.
>
> Doing AC_SUBST([sysconfdir],[/etc]) brings back the original problem and
> doesn't help.
When you use automake, you get all these nice user-controlled things
like --prefix and --sysconfdir (even if you don't want them). I
generally advise to use them instead of working to not use them,
thereby confusing the user who might be running './configure --help'
and seeing that they exist and finding later that your packages is
working to ignore them.
You may find some additional interesting information here (automake
uses autoconf):
http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables
In short, assuming that the configure.ac/Makefile.am you are working
on controls the installation of the c/c++ compiled software that wants
to look for this configuration file, I would recommend against any
configure.ac stuff and instead do something like this in your
Makefile.am:
AM_CPPFLAGS = -DSYSCONFDIR=\"$(sysconfdir)"\
oopsI mean this:
AM_CPPFLAGS = -DSYSCONFDIR=\"$(sysconfdir)\"
This works because automake will supply you with a sysconfdir value
(either a default one, or one provided by the user).
Re: make distcheck and the /etc dir
On 6/4/07, Jason Curl <[EMAIL PROTECTED]> wrote:
Daniel Leidert wrote:
> BTW: If you use
>
> etcdir=${sysconfdir}
>
> you can set
>
> DISTCHECK_CONFIGURE_FLAGS = --sysconfdir=/etc
>
> And if you want to make this the default, set it in your configure
> script:
>
> AC_SUBST([sysconfdir],[/etc])
>
> However, you should carefully think about this. I personally would leave
> it up to the user to choose a directory.
After comments from previous posts I'm thinking how I can then take the
prefix the user provided and put that in "config.h" that the program can
then read to know where the configuration files are. I'll now have to
learn how to extend the installation to make backups of any old
configurations that might be there.
Doing AC_SUBST([sysconfdir],[/etc]) brings back the original problem and
doesn't help.
When you use automake, you get all these nice user-controlled things
like --prefix and --sysconfdir (even if you don't want them). I
generally advise to use them instead of working to not use them,
thereby confusing the user who might be running './configure --help'
and seeing that they exist and finding later that your packages is
working to ignore them.
You may find some additional interesting information here (automake
uses autoconf):
http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables
In short, assuming that the configure.ac/Makefile.am you are working
on controls the installation of the c/c++ compiled software that wants
to look for this configuration file, I would recommend against any
configure.ac stuff and instead do something like this in your
Makefile.am:
AM_CPPFLAGS = -DSYSCONFDIR=\"$(sysconfdir)"\
This works because automake will supply you with a sysconfdir value
(either a default one, or one provided by the user).
Re: make distcheck and the /etc dir
On 6/4/07, Jason Curl <[EMAIL PROTECTED]> wrote: Hello, I have a project where the program expects the configuration files to be stored in '/etc/lx2005'. Appropriately, I've got such a Makefile.am: # Makefile.am for installing configuration data etcdir=/etc/lx2005 I often struggle with this, and have to refer to this FAQ: http://sources.redhat.com/automake/automake.html#Hard_002dCoded-Install-Paths
spaces and distcheck
Hi, From using automake (GNU automake) 1.10 on cygwin, I noticed that 'make distcheck' doesn't work when the build directory contains spaces. This seems to also be true on unix (the reason it was noticed on cygwin is because the default home directory seems to contain spaces). Example: mkdir "dir with spaces" cd "dir with spaces" /path/to/configure make distcheck Thanks, Dave.
passing -R to libtool
I'm using: automake (GNU automake) 1.10 autoconf (GNU Autoconf) 2.61 ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) Given that I don't know where a user has installed prerequisite libraries, I assume the user can pass their location using LDFLAGS. For instance: ./configure LDFLAGS="-L/my/path/to/the/lib" However, for each of these -L in LDFLAGS, I think I would like to have a corresponding -R sent to libtool. Is this correct? What is the best practice for this? Does the user decide to give -R, and if so, what variable, and should I use AC_ARG_VAR() for it? Thanks, Dave.
Re: HPUX: PARALLEL=4 make -P
On 2/14/07, deckrider <[EMAIL PROTECTED]> wrote: On 2/14/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > In other words, this parallel make looks buggy and unusable to me, > and there is really nothing Automake can do about it. > Am I missing anything? Not that I can tell. Thank you for your efforts in simplifying the problem so that it is plain to all. > If you (or someone else who read this far) has a support contract with > HP, please report this as a bug and report back the tracker URL if > publicly available. Thanks. I have reported this bug using your self-contained example: http://www1.itrc.hp.com/service/mcmItrc/viewCallReq.do?callID=3217798259 However, the above URL may not be publicly available without a support contract. Some follow-up was provided by HP on this: "This appears to be a bug. I found a bug report, JAGaf76708, that describes this problem. I found the patch for 11.11, PHCO_31907. I tested it and it does fix the problem. I have not found a patch for 11.23. I will check with the lab and let you know something soon."
Re: HPUX: PARALLEL=4 make -P
On 2/14/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: In other words, this parallel make looks buggy and unusable to me, and there is really nothing Automake can do about it. Am I missing anything? Not that I can tell. Thank you for your efforts in simplifying the problem so that it is plain to all. If you (or someone else who read this far) has a support contract with HP, please report this as a bug and report back the tracker URL if publicly available. Thanks. I have reported this bug using your self-contained example: http://www1.itrc.hp.com/service/mcmItrc/viewCallReq.do?callID=3217798259 However, the above URL may not be publicly available without a support contract.
Re: HPUX: PARALLEL=4 make -P
Hmmm...I think I need more coffee...I hit transmit too soon and I'm now not sure I see the config.status issue at all :( On 2/13/07, deckrider <[EMAIL PROTECTED]> wrote: On 2/12/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jason, all, > > * Jason Kraftcheck wrote on Mon, Feb 12, 2007 at 07:34:25PM CET: > > > > This looks like a race to create .libs by concurrent libtool processes. > > Nope. Unless the output is mangled in order, the link commands are > simply issued too early. This is what I thought at first. However, another characteristic is that I am _not_ able to cause an error through these steps: configure make make clean PARALLEL=4 export PARALLEL while make -P ; do make clean ; done In other words, _after_ config.status runs, it is safe to run in parallel. But as you can see in the log, config.status is at times running _again_ with HP make. Thus, if I do this in Makefile.am, I also don't see errors: $(PROGRAMS): Makefile We also have a very large project, but have not seen this problem in it. Perhaps the reason is that it has a lot of $(BUILT_SOURCES) to generate before it starts compiling and linking, and by the time it compiles and links, config.status has already finished running. But I am not certain of my conclusions ... just reporting some additional behavior that I've seen. > Looks like a bug in HP-UX make. Haven't > reproduced it yet, though. My guess is it doesn't understand inference > rules with separated dependencies, when targets and/or dependencies are > in subdirectories. But I haven't been able to confirm this either. > > > Perhaps libtool should check again to see if the directory exists if mkdir > > fails? > > It does already. > > Cheers, > Ralf -- ASCII ribbon campaign: () against HTML email /\ against Microsoft attachments Information: http://www.expita.com/nomime.html
Re: HPUX: PARALLEL=4 make -P
On 2/12/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: Hello Jason, all, * Jason Kraftcheck wrote on Mon, Feb 12, 2007 at 07:34:25PM CET: > > This looks like a race to create .libs by concurrent libtool processes. Nope. Unless the output is mangled in order, the link commands are simply issued too early. This is what I thought at first. However, another characteristic is that I am _not_ able to cause an error through these steps: configure make make clean PARALLEL=4 export PARALLEL while make -P ; do make clean ; done In other words, _after_ config.status runs, it is safe to run in parallel. But as you can see in the log, config.status is at times running _again_ with HP make. Thus, if I do this in Makefile.am, I also don't see errors: $(PROGRAMS): Makefile We also have a very large project, but have not seen this problem in it. Perhaps the reason is that it has a lot of $(BUILT_SOURCES) to generate before it starts compiling and linking, and by the time it compiles and links, config.status has already finished running. But I am not certain of my conclusions ... just reporting some additional behavior that I've seen. Looks like a bug in HP-UX make. Haven't reproduced it yet, though. My guess is it doesn't understand inference rules with separated dependencies, when targets and/or dependencies are in subdirectories. But I haven't been able to confirm this either. > Perhaps libtool should check again to see if the directory exists if mkdir > fails? It does already. Cheers, Ralf
Re: HPUX: PARALLEL=4 make -P
On 2/10/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: Hello deckrider, Hi Ralf, thanks for the reply. * deckrider wrote on Sat, Feb 10, 2007 at 12:47:23AM CET: > I'm having some parallel problem that isn't always repeatable (as is > the case with many parallel problems) when using HP make as follows: > > PARALLEL=4 make -P distcheck > > I get errors like this: Please post the whole make output. Please also post the configure output. Thanks. Output attached as configure.txt and make.txt I configured as follows: cd bug-1.0.0 mkdir build cd build ../configure I don't always get errors every time, so I ran HP make to create make.txt like this, and used the make.txt that was created when finally seeing an error: PARALLEL=4 export PARALLEL while make -P distcheck > ../../make.txt 2>&1 ; do sleep 1 ; done > It seems that perhaps $(bin_PROGRAMS) depending on Makefile in my > example might be needed to solve this. However, I might expect > Automake to take care of it. What should this have to do with the issues you're seeing? Nothing in the output you posted hints at a rebuild of the Makefile. > I'm attaching bug-1.0.0.zip which is a small project which reproduces > the error on my system: Thanks. > $ uname -a > HP-UX omztdv1 B.11.23 U ia64 2505142627 unlimited-user license > > We have 4 CPUs on this system, which is why we use PARALLEL=4 (I would > guess that this may not be repeatable on a single CPU system). I only have access to single CPU HP-UXen. I don't have enough information to ask intelligent questions yet, though. Cheers, Ralf checking build system type... ia64-hp-hpux11.23 checking host system type... ia64-hp-hpux11.23 checking target system type... ia64-hp-hpux11.23 checking for a BSD-compatible install... .././install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... .././install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for a sed that does not truncate output... /opt/vzb/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - IA64 checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... c++ checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking how to run the C++ preprocessor... c++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 262144 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... hpux11.23 dld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libto
init.d script best practice
Is there a best practice example for using autoconf/automake to install system init scripts? For instance, HP-UX looks for these in /sbin/init.d and /sbin/rc*.d and many others look to /etc/init.d and /etc/rc*.d. Thanks
