Re: Error when using make distcheck
On Wed, Nov 20, 2013 at 09:05:57AM +1000, Peter Johansson wrote: On 11/20/2013 06:45 AM, jerome hamm wrote: Hi, I am trying to pack some software using udev rules, which therefore needs to copy some files to /lib/udev/rules.d. When I try and run make distcheck, at the step where it must install the files in /lib/udev/rules.d it hopelessly fails because of permission issues. My rules (leeched from the upower project) are the following: Makefile.am udevrules_DATA = \ 95-evvgc.rules configure.ac # UDEV for device permission acces setting AC_ARG_WITH([udevrulesdir], AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev rules]), [], [with_udevrulesdir=$($PKG_CONFIG --variable=udevdir udev)/rules.d]) AC_SUBST([udevrulesdir], [$with_udevrulesdir]) Someone in the #autotools channel told that it should try to copy the files in a subfolder of the test folder (not the system root). What I also don't understand is why it doesn't work when I try fakeroot make distcheck ... What am I doing wrong? This sounds more like a question for the automake folks, but have you read this section in the Automake manual: http://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths This has been a bug in automake since forever, and a source of massive frustration. The fix (to automake) is also very simple. The assumption automake makes is that everything you want to install will go under the configured prefix. While this is a nice ideal, reality isn't so simple. Examples: - udev rules (as above) - pam configuration (similar) - nss modules - any third party loadable modules/plugins - cups printer drivers All of the above have a common theme. The software is installed into the configured prefix, but it also needs to integrate with other software which is /already installed into a different prefix/. If I install it into my prefix then the other software won't be able to make use of it. Example: udev isn't going to look in /opt/mypackage/lib/udev/rules.d; it does need installing to /lib/udev/rules.d. automake supports this just fine. It's even already happening outside this special case if you configure with /usr as the prefix with /etc as sysconfdir--it's installing outside the prefix. What's broken is just distcheck; if it set DESTDIR then it would work just fine. As it is, it overrides prefix in a broken way, causing the above problems. In your specific case, because it overrides prefix, and you're not using prefix in your install path, it still tries to use the full path. If it used DESTDIR correctly, it would be able to install it into a staging directory without trouble. I've now encountered this in a number of projects, for all of the above example reasons. In all cases the project built and distributed fine but failed distcheck, and our only choice was to not use distcheck. I've brought the issue up on this list a couple of times, and both times I was told that what I was doing wasn't supported and was buggy. BUT... the important point here is that automake is clearly not supporting the above use cases, so is falling short of the real needs of many projects. Can't we just fix distcheck to use DESTDIR when doing the test install and move on? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Re: Creating plain Makefiles with automake
On Wed, Apr 24, 2013 at 08:36:06AM +0100, Diego Elio Pettenò wrote: On 24/04/2013 00:10, Gavin Smith wrote: My question is, is there any interest in this kind of approach? I feel that it would be a step towards making the GNU build system easier to use and understand. As a distribution developer this seems to me just yet another hack that is going to cause us great pain in the future if it is found in the wild.. I'm not sure I see why. It has the virtue of removing a step of indirection in the intermediary Makefile.in, and so serves to simplify things. Including the substituted variable definitions via a separate file would also serve to make things more robust: there's only a single source for them, rather than duplicate definitions across every Makefile.in. And it's now possible to have rules depend upon the Makefile.am, Makefile and/or the configuration data which can then be used to trigger Makefile regeneration and rebuilds in a more informed manner, avoiding some of the rebuilds that now occur since you've decoupled the make logic and configuration logic. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Non-recursive automake and double-colon rules
Hi, Just a suggestion for the documentation: If you switch to non-recursive make (i.e. no use of SUBDIRS), but you want to use include to retain Makefile.ams in subdirectories, you end up running into problems when you have multiple copies of -local and -hook rules. For example, I have % grep include Makefile.am include $(top_srcdir)/scripts/global.mk include $(top_srcdir)/scripts/git-dist.mk include etc/Makefile.am include etc/pam/Makefile.am include etc/setup.d/Makefile.am include etc/bash_completion/Makefile.am include contrib/setup.d/Makefile.am include doc/Makefile.am include doc/historical/Makefile.am include man/Makefile.am include sbuild/Makefile.am include bin/schroot-listmounts/Makefile.am include bin/dchroot-dsa/Makefile.am include bin/csbuild/Makefile.am include bin/dchroot/Makefile.am include bin/schroot-sbuild/Makefile.am include bin/schroot-releaselock/Makefile.am include bin/schroot-base/Makefile.am include bin/schroot-mount/Makefile.am include bin/schroot/Makefile.am include test/Makefile.am % git grep -E '(-hook|-local):' Makefile.am:dist-hook:: bin/csbuild/Makefile.am:install-exec-hook:: bin/dchroot-dsa/Makefile.am:install-exec-hook:: bin/dchroot/Makefile.am:install-exec-hook:: bin/schroot-sbuild/Makefile.am:install-exec-hook:: bin/schroot/Makefile.am:install-exec-hook:: bin/schroot/Makefile.am:install-data-hook:: doc/Makefile.am:clean-local:: etc/Makefile.am:all-local:: profiles etc/Makefile.am:install-data-hook:: etc/Makefile.am:clean-local:: etc/setup.d/Makefile.am:install-exec-hook:: man/Makefile.am:clean-local:: man/Makefile.am:all-local:: man-update-po $(TRANSMAN) man/Makefile.am:dist-hook:: man-update-po test/Makefile.am:clean-local:: I've used GNU make double-colon rules to allow the same target to be used multiple times. While this is GNU make-specific, it's a simple and effective way to convert an existing recursive automake setup to being nonrecursive. Possibly worth putting in the documentation (along with a portability caveat?) I'd be interested to know what other people's experiences have been here. While I could move everything into the top-level Makefile.am, keeping rules together with the files they operate on does have some advantages. What about po/Makefile.in.in? Is there a nonrecursive variant of this available? The nonrecursive build is massively faster than the old recursive build, so quite a worthwhile improvement for this project! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
On Tue, Aug 14, 2012 at 06:57:02PM -0500, Bob Friesenhahn wrote:
AC_INIT(m4_esyscmd([scripts/pkginfo.sh package_name]),
m4_esyscmd([scripts/pkginfo.sh package_version]),
m4_esyscmd([scripts/pkginfo.sh package_bugreport]))
Unfortunately, the values passed to AC_INIT are cached so even if
the configure script is run again, it uses the cached values rather
than the new values.
I've been doing a similar thing, though I do it directly in configure.ac
rather than using an external script:
AC_INIT(sbuild_m4_esyscmd_s([sed -ne
'/^Package:/{s/Package:[[:space:]][[:space:]]*//p;q}' VERSION]),
[sbuild_m4_esyscmd_s([sed -ne
'/^Version:/{s/Version:[[:space:]][[:space:]]*//p;q}' VERSION])],
[buildd-tools-de...@lists.alioth.debian.org])
In this case, the information is taken from a static file with the format:
Package: schroot
Version: 1.6.3
Release-Date: 23 Jul 2012
Released-By: Roger Leigh rle...@debian.org
Git-Tag: release/schroot-1.6.3
This is generated by the bootstrap script.
Package and Version are derived from NEWS (since this must be updated
for a release, we require the version here to be the definitive source
of the version.
The other date is taken from the release tag in git; if it's not a
release, i.e. isn't tagged, it's just left as Unreleased.
Your version is better, because it permits vanilla autoreconf to be
used. Providing that we have a stable interface for autoconf to
call an external script, packages could do whatever they wish to
provide the information. Maybe a single-argument AC_INIT which
just has a script file as its argument? However it's done, having
this standardised would be beneficial to all.
In addition to it invoking the script with arguments for
package, version and bugreport address, it might also be nice to
provide the ability to supply information for arbitrary other
stuff such as
- public git URI
- public website
- public bug tracker
- git release and distribution tags
- git branch
And perhaps also allow this to be extended by the builder/distributor,
for example with
- build date
- builder
- distribution
- distribution bug tracker etc.
These are all examples of things which are currently done by some
packages on an ad-hoc basis, but which would benefit from more
generalised support in autoconf. Maybe add a command-line option
to run additional script(s) to source supplementary/overriding
information?
On the automake side, I'm still using custom targets for git integration
with make dist which inject $(distdir) into a separate git branch and
tag that as a distribution; a separate step tags the release, which
is then distributed. If it's not possible to support directly in
automake, being able to disable tarball generation in the dist target
and do completely custom stuff there would be useful. In particular,
having a logical separation of releasing and distributing would be
good.
One thing which is currently done wrong is that some stuf, e.g.
gettext, tries to regenerate stuff at make dist time. This is
rather annoying, as it's creating updated versions of files /after/
you've tagged the release. This means you need to run make dist, then
tag, then run make dist again. While workable, it's easy to forget and
mess up the release process. When you're using a DVCS, this is the wrong
point. We only want to tag the release /after/ all sources changes have
been made and *committed*. Thus there are three steps:
1) release preparation
- updates any files e.g. gettext po files etc.
- commit any changes resulting from this step
2) release
- tags the repo with a signed release tag
3) distribution
- makes the distdir and injects it onto a distribution branch
- branch is tagged
- release tarball is obtained (if required) using git archive
to export the tagged distribution. Not needed for an all-git
workflow (e.g. future Debian git source package format).
The existing make dist does of course do everything in a single
step; but it would be nice if these were split into separate,
overridable/hookable targets, and tools like gettext updated to
run in the release prep stage.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Re: Autoconf caches AC_INIT arguments
On Wed, May 23, 2012 at 04:14:00PM +0200, Stefano Lattarini wrote:
Hi Bob.
On 05/23/2012 02:17 AM, Bob Friesenhahn wrote:
The forthcoming Automake release is about to break the means I have been
using to automatically version my package (without manually editing
configure.ac) for the past 9 years.
I smell a misunderstanding here: Automake 1.12.1 will only start *warning*
about such an usage, but will still work with it (there are checks in the
Automake test suite that should verify this is indeed the case). The actual
removal of support for that usage will only take place in Automake 1.13, which
I don't see appearing if not several several months from now (i.e,, until
there is some major feature or non trivial bug-fix that justifies a new major
release).
I will try to answer the rest of your message by today (or tomorrow).
I'm currently using the following scheme in a number of projects (in
this case, taken from schroot):
(Includes some compatibility hacks for earlier autotools versions.)
dnl m4 magic from Eric Blake e...@byu.net, prior to automake inclusion
m4_define([sbuild_m4_chomp],
[m4_format([[%.*s]], m4_bregexp(m4_translit([$1], [
]]m4_dquote(_m4_defn([m4_cr_all]))[, [/]]m4_format([%255s], [])[),
[/*$]), [$1])])
m4_define([sbuild_m4_esyscmd_s],
[sbuild_m4_chomp(m4_esyscmd([$1]))])
AC_PREREQ(2.59)
dnl Quoting the first argument results in a bizarrely corrupted package tarname
AC_INIT(sbuild_m4_esyscmd_s([sed -ne
'/^Package:/{s/Package:[[:space:]][[:space:]]*//p;q}' VERSION]),
[sbuild_m4_esyscmd_s([sed -ne
'/^Version:/{s/Version:[[:space:]][[:space:]]*//p;q}' VERSION])],
[buildd-tools-de...@lists.alioth.debian.org])
In the above, the VERSION file is generated from NEWS and git to
contain metadata about the release, including the package, version,
person releasing the package, release date etc. This is done by
the bootstrap script, which runs autoreconf afterward.
Essentially, I have no desire to hardcode any of the release
metadata such as the version into configure.ac. The above is my
own custom hack to generate and incorporate the metadata, but I
would happily adopt a more standard and generic solution if
possible.
What is the recommended way to use autoconf/automake in this type
of scenario?
Thanks,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Re: GSoC project idea: non-recursive automake project
On Mon, Mar 21, 2011 at 11:49:39AM -0400, NightStrike wrote: On Sat, Mar 19, 2011 at 3:45 PM, Harlan Stenn st...@ntp.org wrote: Pippijn wrote: On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: If there was a student interested in showing how easy it was to use automake to do non-recursive Makefiles for a project, I'd be willing to co-mentor and work with them to convert NTP to that sort of operation. It's mostly trivial. How hard are GSoC projects supposed to be? I'll assume you have seen my reply to Ralf. From my POV, I have heard folks saying for a long time how easy it is to use automake to produce non-recursive Makefiles. But I haven't seen this in practice, and on the (few) attempts I have made to figure it out myself and look for examples, I have not yet been able to find a really useful solution. A solution to *what* exactly? Said another way, what *exactly* is the problem with automake+non-recursion that you would want solved? I personally have found that the only obstacle to me is minor -- all sources have to be specified relative to the top level directory, even in a subdir Makefile fragment that gets included in the top. Surely even this is a solvable problem. Can't automake rewrite the relative paths to be absolute? Obviously this wouldn't necessarily work for some complex custom rules, but in the general case it would be a big bonus. It would also mean that any variables such as foo_SOURCES in a subdirectory could have the absolute path prefixed to all the files on inclusion, which would mean I could convert to using a single top-level Makefile and keep all the separate Makefile.ams in the subdirectories, where it makes sense to have them alongside the code they build. I certainly wouldn't be averse to rewriting any custom rules to gain this. I've wanted something like this for years, in fact. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: PKG_CHECK_MODULES on system without pkg-config installed?
On Thu, Mar 10, 2011 at 11:38:16AM +0100, Vincent Torri wrote: On Thu, Mar 10, 2011 at 11:02 AM, Jef Driesen jefdrie...@hotmail.comwrote: mi...@gnu.org wrote: Jef Driesen writes: Isn't it easier to just check for the presence of the header file and/or the library file, avoiding pkg-config entirely? Well, I'd prefer not to guess when possible, and not using pkg-config for a package that wants you to use it means you end up guessing at the proper locations/settings. Maybe this often works, but why risk it when it's not necessary? I'm aware of the advantage of using pkg-config. I even supply the *.pc files for my own projects. But the point is that if I want to support systems that don't have pkg-config installed (like Mac OS X in my case), I have to provide a fallback with manual detection anyway. So why not skip pkg-config entirely? You also have to support static linking. This is not meant to sound like a troll, but: is anyone really *really* using static linking in 2011? We go through great pains to support it, but I can't even remember the last time I even /tried/ to link something statically. Maybe 2001? I do like to support pkg-config in my packages, but I don't do it for the static linking support. Is the gain actually worth the effort? Is static linking support actually tested regularly in most packages? (I suspect very much not.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [CRAZY PROPOSAL] Automake should support only GNU make
On Wed, Jan 12, 2011 at 07:01:47PM +0100, Stefano Lattarini wrote: To be honest, I'm starting to agree with Ralf more and more on these issues; i.e., just ... require a decent make ;-). And more than this -- brace yourself -- I'm starting to think that automake should *really* start supporting *only* GNU make (at least from version 3.75 or so). [...] I certainly agree that there are several advantages to requiring GNU make. But I don't think you touched on the most common practical problem with the current situation. In theory, automake is portable and targets any make providing the basic POSIX/SUS-specified functionality. In reality, many (most?) automake- using projects fail to build with non-GNU make. This is /not/ because of any deficiencies with automake, it's because the Makefile.ams are only ever tested with GNU make, and so any nonportable constructs are not picked up on. Without regular testing using a set of different make variants, we end up supporting GNU make by default--because that's what the overwhelming majority of developers and users are using. In a number of projects I maintain the build infrastructure for, we already mandate GNU make. This is just reflecting a simple reality: we don't have the resources to continually test for and fix portability issues in the Makefiles. And if we do take the time to do this, it's rapidly broken again because testing with GNU make doesn't pick up any regressions. We also don't have /any/ feedback from non-GNU make users telling us about portability issues, so GNU make becomes a /de facto/ requirement in any case. Supporting non-GNU makes just isn't worth the effort--we gain nothing from it. Note I'm not suggesting that automake immediately stop being portable to other makes. But I don't believe it's serving a useful purpose for the vast majority of automake users. I would find it useful to make use of more advanced GNU make-specific features on occasion, without automake complaining! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: default -g ??!?
On Sat, Nov 20, 2010 at 10:36:34AM -0500, MK wrote: Ah, it's because of GNU make: By default, the Make rules should compile and link with -g, so that executable programs have debugging symbols. Users who don't mind being helpless can strip the executables later if they wish. Nice, flexible software it ain't. This is an assbackward policy. The idea that general, non-programmer users will be helpless without debugging symbols is completely absurd. What actual problems are the debugging symbols causing you? What is the wrong with the default? If and when you do need debugging symbols, it should be easy to opt *for* them. Instead, I am left with the choice of leaving them in by default, or having to use strip, making it impossible to add them. Automake already provides an install-strip target for just this purpose. Most users are unaware if they are running stripped or unstripped binaries, but when a user runs into problems, it's nice to have unstripped binaries around for diagnostic purposes. It's also contrary to the defaults, and what most people would expect, given that pretty much every other automake-using package does the opposite of what you want! For Debian at least, we want unstripped binaries by default. We'll do the stripping later. There is a reason for this. We provide -dbg packages, which nowadays contain detached debugging symbols. The dh_strip program handles this as already mentioned. In the future, we may end up taking a similar path to Ubuntu and automatically produce .ddebs (debug .deb packages) containing the stripped debug info for every single package built, or even allow direct download of symbols from a central database. Having unstripped binaries is contrary to all these goals. Note that this is not unique to Debian; all distributions want to have debug symbols for end-user diagnostics, and we don't want to ask the user to recompile with debug symbols enabled--they would then not be using the same binaries, which might not exhibit the same behaviour. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Silencing doxygen output
On Wed, Nov 10, 2010 at 10:45:03PM +1100, Erik de Castro Lopo wrote: Hi all, I'm using AM_SILENT_RULES([yes]) to silence make output and I'm pretty happy with it. However, I have a doxygen command in a Makefile.am: doxygen reference.doxygen and I can't figure out how to silence it. Clues? I use: foo.log: foo.dox $(top_srcdir)/configure $(RM) -rf foo/html $(DOXYGEN) foo.dox touch $@ @UNDOCUMENTED=$$(cat $@); \ if [ -n $$UNDOCUMENTED ]; then \ echo -- UNDOCUMENTED CODE --; \ echo $$UNDOCUMENTED; \ fi with WARN_LOGFILE in foo.dox. I would suggest just redirecting the doxygen output to another file when running silently. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: automake po / pot file integration: when to merge the PO files?
On Mon, Sep 06, 2010 at 11:25:44AM +0200, Bruno Haible wrote: Hi, One issue still needs discussion within the planned po / pot file integration [1]: When should the PO files that are distributed be merged with the POT file? Just a few comments from a long-time gettext+automake user which I hope might be useful: The number one problem for me (as you identified) is the huge churn in po file content as you make source changes. I'd like to suggest that the best way to tackle the problem is to simply stop generating the source file/line number comments by default; I'm already doing this in some of my projects by adding --no-location to XGETTEXT_OPTIONS in po/Makevars. It's a massive improvement. Making this small change has a huge impact. po file changes are now sensible: they match source string changes only, not massive line renumbering because I added/removed some unrelated code. This makes merging between branches sensible because I don't have an entire po file full of line number conflicts I can't hope to merge manually. A question I have is what purpose does having the line number and source file serve? Do those benefits outweigh the massive disadvantages? And if the original source file(s) for a string need to be found, grep(1) is pretty fast. At least for me, the translators get mailed the po file, and never look at the source, so it's not of *any practical benefit* to anyone AFAICS; I've certainly had no complaints since I turned them off. With this change made, I would be fully in favour of having update-po run by default so that the po files are always kept up-to-date. In this situation, it makes sense--the po file changes are *entirely related* to the source changes, and can be committed together. Updating the po files by default also makes releases easier: if I tag a release and then make dist and find all the po files were updated, modifying the repository, I need to detag, commit the changes and retag. Updating by default means the repository is always in a releasable state whereby any revision can be tagged without doing additional sanity checks. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
git-based release and distribution management for automake
Hi, Last year, I wrote to the list to show an initial demonstration of integrating automake with git version control. This work has been largely dormant since then, but over the last couple of weeks I have completed an initial fully working implementation which may be of interest to others. The aim behind this is to increase the robustness of making releases and to keep the actual distributed releases under version control; normally while the sources are under version control, the verbatim output of make dist is not since it's packed into a tarball. Downstream distributors may subsequently put that under version control, but here it's done directly, skipping tarball generation entirely. Downstreams may now simply clone the upstream repo and work directly with it; tarballs as a distribution format may be omitted entirely. Currently some projects make GPG signatures of their release tarballs so that their integrity may be verified. Here, we have GPG signed tags which verify not only the distribution of a release, but also its parent tagged release in git and all prior history, providing a new level of integrity checking to the release process. Downstream changes can be traced all the way back as well. I've attached a Makefile fragment which can be included into your top-level Makefile.am. This adds three main rules: • check-git: Checks that the working tree and index are clean, and that no untracked files are present. This ensures that no files are distributed which aren't either under version control or generated by autoconf/make (and are therefore in .gitignore). • release-git: Tags the current HEAD with an (optionally signed) release tag. • dist-git: The main rule; injects $(distdir) onto a distribution branch and tags it with an (optionally signed) distribution tag. This automatically calls the check-git and release-git rules and aborts if the tree is dirty or the working tree doesn't match the release tag. There's also a dist-git-generic rule which skips some of the checks, and is used to retrospectively inject past distributed releases into git (and tie them to the release history). The file contains documentation on the use of each rule and how to customise for individual projects. Any comments would be appreciated. The terminology used may not entirely fit with existing automake terminology (release vs distribution), and could easily be changed. Future work will add support for pristine-tar so that the distributed release tarball can be recreated bit-for-bit identically to the original directly from the distribution branch. An example of what this looks like in a real-world scenario: git://git.debian.org/git/buildd-tools/schroot.git Check out the distribution-1.4 branch (for example) and look at the history with gitk to see how the distribution history ties up with the release history and other branches in the repository. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. # Automake support for git-based release and distribution management # # # Copyright © 2009-2010 Roger Leigh rle...@debian.org # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see # http://www.gnu.org/licenses/. # # # Include this file in your top-level Makefile.am using # include $(top_srcdir)/scripts/git-dist.mk # (for example) # Note that this script uses GNU make-specific functions, and so run # automake with -Wno-portability or add this to the automake options # in configure.ac. # Customise using the following variables. See below for instructions # on what each variable does. Note that these could be overridden in # the Makefile including this Makefile fragment, so this file doesn't # need editing directly. # Check for untracked files in working tree GIT_CHECK_UNTRACKED=true # GPG sign release tags GIT_RELEASE_TAG_SIGN=true # Naming scheme for release tags. Note: must include $(VERSION). GIT_RELEASE_TAG_NAME=release/$(PACKAGE)-$(VERSION) # Message for release tags. GIT_RELEASE_TAG_MESSAGE=Release of $(PACKAGE)-$(VERSION) # GPG sign distribution tags
Re: GNU make or portable make? (was: Makefile to Makefile.am)
On Tue, Aug 17, 2010 at 10:05:31PM +0200, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Mon, Aug 16, 2010 at 05:06:40PM CEST: If depending on GNU make was considered ok, then Automake would have been developed quite differently than it is. Given current Automake objectives, it is wise that individual projects also try to avoid GNU make syntax in Makefile.am. While I don't dispute that, I do think that requiring GNU make is a fairly low barrier in way of prerequisites. GNU make is small, highly portable and easily installed. If Automake were only started now, I think requiring GNU make would be a prudent design decision. The current Automake code contains large chunks of logic that exists purely to work around missing features or issues in non-GNU make implementations. Let's be honest, requiring GNU make outright would make several optimizations possible, leading to smaller makefiles and lower build system overhead. We've been at the point before where some new feature was easily implemented in GNU make syntax but rather tough in portable make. Some features may not be possible at all with the latter. As someone who tried hard to keep their project's Makefiles portable across all vendor make variants, I'd just like to point out that in practice most projects end up dependent upon GNU make, even if that wasn't their deliberate intention. If your primary development environment is GNU-based such as GNU/Linux, or even MSYS, your primary testing is always with GNU make and non-portable things won't be found. I spent a lot of time making sure BSD and Solaris makes worked correctly, but unless you've got people testing every release against all other makes, GNU make-isms gradually creep back in. In my case the cost of the testing was not worth the benefit--no one else was using those platforms regularly enough and we ended up simply mandating GNU make in any case. A similar story has played out for all of the projects I've been involved with: while in theory automake produces portable Makefiles, in practice they are not. The reality was that for the odd single user using BSD who ran into problems, the answer was just to build with gmake. I for one would be glad if automake required GNU make, since it could make use of a lot of useful features which currently aren't allowed. Similar to autoconf not requiring a POSIX shell, depite the fact that non-POSIX shells are so far obsolete they are irrelevant. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Integration of git-based release workflow into make dist
On Fri, Aug 14, 2009 at 07:53:46PM +0200, Ralf Wildenhues wrote: Hello Roger, * Roger Leigh wrote on Fri, Aug 14, 2009 at 11:40:18AM CEST: An initial implementation follows. This works, but it does need further refinement (error checking, for example). And probably review by a git expert. I'm sure other people can make it much nicer, but this hopefully demonstrates the point. Thanks. Not to sound discouraging, but this seems to be able to cope mostly without any Automake internals (am__remove_distdir is a rather benign issue) nor need special help from Automake. That means it can easily live outside of Automake proper for a while at least, until it is settled and useful for more than a couple of projects or distros, as Bob already noted. You can keep it synchronized across projects easily by putting the code into a fragment.am file and including that into your toplevel Makefile.am, and synchronizing the fragment, no? Absolutely. I am perfectly happy in doing so. I've attached a new version to this mail, with these changes: • error checking • VPATH support • checking for already-tagged repos • tagging of both release and distribution branches • customisation of both release and distribution tagging behaviour, as well as allowing it to be skipped e.g. make dist-git GIT_RELEASE_TAG=false You could consider submitting this fragment as a gnulib module (where you just place your code into the Makefile.am part of the modules/.. file. Or as part of maint.mk, if the gnulib crowd likes that better. I hadn't come across this before; I didn't realise it had Makefile.am fragments as well. That's perfectly OK by me. How does one extract these bits into a project's Makefile.am automatically? Or is it just a matter of copying and pasting the needed bits? * Roger Leigh wrote on Sat, Aug 15, 2009 at 12:13:21PM CEST: Additionally, VCSes don't typically store the results of make dist, only the source for that. Due to changing tool versions over the years, you can get in a situation where you can no longer rebootstrap checkouts of old versions. By storing this in the VCS as well, you guarantee that you can get a usable tree even if those tools are no longer available or functional. Plus, you can also diff the generated files between releases as an added bonus, which can help track down build infrastructure issues. I think your solution is pretty cool, and goes to show again how nice it is that git is so versatile. I might consider using it for future Automake releases. But as to inclusion in Automake proper, I'm still slightly on the side of this is git-centric and probably a bit Debian-centric in the sense that other distros or other developers might want to choose to do it a bit differently, and I'd rather have Automake offer generic solutions. Are you coordinating with other distros? Some feedback from others would certainly not hurt here. I'm going to run it past the git list in case there are any technical flaws in what I'm doing. I haven't yet discussed it with anyone else; I thought bringing it up on this list would be best initially. I think other git-using automake users are the best people to provide feedback, rather than distributors, since they are the primary audience. I'm not quite sure how best to contact them though, other than this list and the git list. I've made the release and distribution tag and commit stuff completely configurable by make variables. However, you are correct that this is rather git-specific. There are problems making this more general: • different VCSes have different restrictions on tag names; CVS doesn't allow '.' so will break on $(VERSION), others don't allow '/'. The default tag name scheme will out of necessity need to be tailored to each VCS. Different projects also have different rules, so it's highly likely this will need to be customised from whatever default we pick. • Not all VCSes support GPG signing of commits and/or tags. This is geared to signing tags, but could be generalised to also allow signing commits. • VCS branch naming limitations; the branch name chosen here contains no odd characters, so should be fine. (Unless you're using GNU Arch. But then you have bigger problems!) The design of the rest (rather than this specific implementation) is generic: committing a copy of the distdir onto a specified branch is possible in all VCSes I know; the difficultly of actually implementing this in automake is the main challenge here. It might be worth bringing up this on the relevent VCS mailing lists in order to generalise what can be sensibly generalised. However, I don't think it should be a requirement to support multiple version control systems /at the same time/. One typically only develops in a particular VCS type, even if it gets mirrored in others. In your earlier mail: As to package versioning, see this discussion and references therein: http
My approach for moving PACKAGE and VERSION
Hello again,
Following the earlier thread a few months back
(RFE: allow for computed version number), I was looking for a
solution to this problem at the time, and implemented a scheme
similar to that proposed. In case it's useful for anyone else, I'll
detail what I'm doing below.
I use git, and end up having the PACKAGE and VERSION in multiple
places, including:
configure.ac
NEWS
git release tags
Being able to eliminate some of this redundant information would
be great. The scripts and files below /are/ hacky; having some
support for this in the tools would remove most, if not all, of
that:
I think looking at the bigger picture, what would be really useful
would be for both autoconf and automake to have a generalised
mechanism for getting information about a package. This could be
as simple as calling a hook script which is written by the user.
Like the script below, it could return key: value pairs and parse
out the needed bits, or it could have an argument requesting the
wanted bit of information.
This script could get the information directly from the VCS and/or
files in the source distribution (so it will work both with and
without the presence of a VCS).
Information that would be useful:
PACKAGE
VERSION
Release date
Distributor/Origin (to indicate origin if redistributed modified)
[already hacked into e.g. binutils and gcc; having a standardised
method would be good]
Regards,
Roger
bootstrap
═
Call a script git-version to generate a VERSION file, containing the
information necessary for configure.ac and then autoreconf.
NOTE: automake --gnu requires a ChangeLog, but nowadays this might be
generated at make dist time; please consider making --gnu mandate a
changelog in $distdir instead. This has the same result for the end
distributed source, but doesn't constrain the developer to maintain a
manually written changelog.
─[bootstrap]───
#!/bin/sh
set -e
# Generate version information from git release tag
./scripts/git-version VERSION
# To satisfy automake
touch ChangeLog
# Bootstrap autotools
autoreconf --verbose --force --install
rm -rf autom4te.cache
───
VERSION
═══
Generated using the git-version script (see below)
─[VERSION]───
Package: sbuild
Version: 0.59.1-rc1
Release-Date: 02 Aug 2009
Released-By: Roger Leigh rle...@debian.org
Git-Tag: release/sbuild-0.59.1-rc1
───
configure.ac
Similar to what others are doing. I just changed the command to parse
the particular syntax in my generated VERSION file above. I've just
added a prefix so I don't conflict with autoconf/automake's
implementation.
─[configure.ac]
dnl m4 magic from Eric Blake e...@byu.net, prior to automake inclusion
m4_define([sbuild_m4_chomp],
[m4_format([[%.*s]], m4_bregexp(m4_translit([$1], [
]]m4_dquote(_m4_defn([m4_cr_all]))[, [/]]m4_format([%255s], [])[),
[/*$]), [$1])])
m4_define([sbuild_m4_esyscmd_s],
[sbuild_m4_chomp(m4_esyscmd([$1]))])
AC_PREREQ(2.59)
dnl Quoting the first argument results in a bizarrely corrupted package tarname
AC_INIT(sbuild_m4_esyscmd_s([sed -ne
'/^Package:/{s/Package:[[:space:]][[:space:]]*//p;q}' VERSION]),
[sbuild_m4_esyscmd_s([sed -ne
'/^Version:/{s/Version:[[:space:]][[:space:]]*//p;q}' VERSION])],
[buildd-tools-de...@lists.alioth.debian.org])
───
git-version
═══
I use a tagging scheme where releases are named
release/PACKAGE-VERSION
so we get the version by looking for the release tag, chopping it up,
and then writing out the information, which includes other information
such as the release date and who make the release. The release date
is currently also used in configure.ac and then AC_DEFINED.
Yes, this is backwards. You shouldn't have to tag the release prior
to actually making it. This means I now create -rc1 version tags after
making a release in order to get a sensible release number. Ideally,
I should get that from NEWS, as done below for the tagging script, and
create the release version in dist-hook.
─[git-version]─
#!/bin/sh
TAG=$(git describe --abbrev=0 --match='release/*')
PKGVER=${TAG#release/}
PACKAGE=$(echo $PKGVER | sed -e 's/^\([^-]*\)-\(.*\)$/\1/')
VERSION=$(echo $PKGVER | sed -e 's/^\([^-]*\)-\(.*\)$/\2/')
COMMIT=$(git rev-parse $TAG^{})
COMMIT_DATE=$(git log -1 --date=iso $COMMIT --pretty=format:%ad)
RELEASE_DATE=$(date --date=$COMMIT_DATE '+%d %b %Y')
RELEASE_BY=$(git show $TAG | sed -ne
'/^Tagger:/{s/Tagger:[[:space:]][[:space:]]*//p;q}')
echo Package: $PACKAGE
echo Version: $VERSION
echo Release-Date: $RELEASE_DATE
echo Released-By: $RELEASE_BY
echo Git-Tag
Re: Integration of git-based release workflow into make dist
On Fri, Aug 14, 2009 at 12:07:39AM +0100, Roger Leigh wrote: This is a rough outline of what I'd like to do (unless someone beats me to it!) • Add a dist-git option and Makefile target. This will cause $distdir to be injected into git, rather than just calling tar as for other git targets. • This will require some additional options in order to work correctly: · A branch name (the head to append the new tree to) · [optional] Tag name, could be a pattern such as dist/$(VERSION) · [optional] Flag for signing the tag or not . [optional] Template commit message These could all just be variables in the top-level Makefile.am. An initial implementation follows. This works, but it does need further refinement (error checking, for example). And probably review by a git expert. I'm sure other people can make it much nicer, but this hopefully demonstrates the point. The distributed release is put on a distribution branch, and its parents are both the previous release and the current head. i.e. it's a merge of the old distributed release and the current release. This lets you do easy merging of changes between both branches, with a correct history. Regards, Roger GIT_DIST_BRANCH=distrib GIT_DIST_COMMIT_MESSAGE=Distribution of $(PACKAGE) version $(VERSION) GIT_DIST_TAG=true GIT_DIST_TAG_NAME=dist/$(PACKAGE)-$(VERSION) GIT_DIST_TAG_MESSAGE=Distributing $(PACKAGE)-$(VERSION) dist-git: distdir DISTDIR_INDEX=$(distdir).git.idx; \ rm -f $$DISTDIR_INDEX; \ GIT_INDEX_FILE=$$DISTDIR_INDEX GIT_WORK_TREE=$(distdir) git add -A; \ GIT_INDEX_FILE=$$DISTDIR_INDEX TREE=$$(git write-tree); \ rm -f $$DISTDIR_INDEX; \ DIST_HEAD=$$(git show-ref -s HEAD); \ COMMIT_OPTS=-p $$DIST_HEAD; \ DIST_PARENT=$$(git show-ref --heads -s refs/heads/$(GIT_DIST_BRANCH)); \ if [ -n $$DIST_PARENT ]; then \ COMMIT_OPTS=$$COMMIT_OPTS -p $$DIST_PARENT; \ fi; \ COMMIT=$$(echo $(GIT_DIST_COMMIT_MESSAGE) | git commit-tree $$TREE $$COMMIT_OPTS); \ git update-ref refs/heads/$(GIT_DIST_BRANCH) $$COMMIT; \ TAG_OPTS=; \ if [ $(GIT_DIST_TAG) = true ]; then \ TAG_OPTS=$$TAG_OPTS -s; \ fi; \ git tag -m $(GIT_DIST_TAG_MESSAGE) $$TAG_OPTS $(GIT_DIST_TAG_NAME) $$COMMIT; $(am__remove_distdir) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Integration of git-based release workflow into make dist
Distribution of $(PACKAGE) version $(VERSION) [|gpg --clearsign] | git commit-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 ⇒ 04bd8ea48e17d845d22cfcfb10bde1a4dee06caf % git update-ref refs/heads/distribution 04bd8ea48e17d845d22cfcfb10bde1a4dee06caf % git tag -s ... This could possibly be provided as a separate script, rather than in the generated Makefile, but would probably be more flexible if put in the Makefile. Debian has now got a new source package format, which includes (currently experimental) support for git as a source distribution format. With the above missing piece in place, it will be possible to have all the sources in git from upstream to distributor to end user, with an complete GPG signed history of all changes made by upstream and the distributor (and any other distributors downstream of Debian). Of course, the feature as proposed has many other uses than this, but that's where I'd like to get to! Any thoughts or comments? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
make distcheck fail due to unset DESTDIR
Hi folks, In a Makefile.am, I have the following: -- if BUILD_DEBVERSION pg_server_lib_LTLIBRARIES = \ debversion.la debversion_la_SOURCES = \ debversion.cc debversion_la_CXXFLAGS = -I$(pg_server_includedir) debversion_la_LDFLAGS = -module -avoid-version $(APT_PKG_LIBS) pg_contrib_DATA = \ debversion.sql \ uninstall_debversion.sql endif debversion.sql: debversion.sql.in sed 's,MODULE_PATHNAME,$$libdir/$*,g' $ $@ However, make distcheck fails, with: make[3]: Entering directory `/home/rleigh/sbuild/sbuild-0.58.0/_build/db' make[3]: Nothing to be done for `install-exec-am'. test -z /usr/share/postgresql/8.3/contrib || /bin/mkdir -p /usr/share/postgresql/8.3/contrib /usr/bin/install -c -m 644 'debversion.sql' '/usr/share/postgresql/8.3/contrib/debversion.sql' /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3/contrib/debversion.sql': Permission denied /usr/bin/install -c -m 644 '../../db/uninstall_debversion.sql' '/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql' /usr/bin/install: cannot create regular file `/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql': Permission denied The rule itself looks OK: install-pg_contribDATA: $(pg_contrib_DATA) @$(NORMAL_INSTALL) test -z $(pg_contribdir) || $(MKDIR_P) $(DESTDIR)$(pg_contribdir) @list='$(pg_contrib_DATA)'; for p in $$list; do \ if test -f $$p; then d=; else d=$(srcdir)/; fi; \ f=$(am__strip_dir) \ echo $(pg_contribDATA_INSTALL) '$$d$$p' '$(DESTDIR)$(pg_contribdir)/$$f'; \ $(pg_contribDATA_INSTALL) $$d$$p $(DESTDIR)$(pg_contribdir)/$$f; \ done It contains DESTDIR, and DESTDIR is set in the top-level Makefile in the distcheck rule. So I'm not sure where the cause of this failure lies-- I can't see anything obvious in the Makefile.am. I tried removing the automake conditional in case that screwed things up subtly, but it makes no difference. I'm using automake-1.10.1 on Debian GNU/Linux. The full source is at: http://nagini.codelibre.net/~rleigh/sbuild-0.58.0.tar.gz (db/Makefile.am is the Makefile in question.) Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: make distcheck fail due to unset DESTDIR
On Sat, Feb 28, 2009 at 03:38:42PM +0100, Ralf Wildenhues wrote:
* Roger Leigh wrote on Sat, Feb 28, 2009 at 03:14:27PM CET:
pg_contrib_DATA = \
debversion.sql \
uninstall_debversion.sql
However, make distcheck fails, with:
make[3]: Entering directory `/home/rleigh/sbuild/sbuild-0.58.0/_build/db'
make[3]: Nothing to be done for `install-exec-am'.
test -z /usr/share/postgresql/8.3/contrib || /bin/mkdir -p
/usr/share/postgresql/8.3/contrib
/usr/bin/install -c -m 644 'debversion.sql'
'/usr/share/postgresql/8.3/contrib/debversion.sql'
/usr/bin/install: cannot create regular file
`/usr/share/postgresql/8.3/contrib/debversion.sql': Permission denied
/usr/bin/install -c -m 644 '../../db/uninstall_debversion.sql'
'/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql'
/usr/bin/install: cannot create regular file
`/usr/share/postgresql/8.3/contrib/uninstall_debversion.sql': Permission
denied
The full source is at:
http://nagini.codelibre.net/~rleigh/sbuild-0.58.0.tar.gz
The problem is likely this code in configure.ac:
AC_MSG_CHECKING([for PostgreSQL architecture-independent support files
directory])
pg_server_sharedir=`$PG_CONFIG --sharedir`
AC_ARG_WITH([debug], [AS_HELP_STRING([--pg-server-sharedir], [PostgreSQL
architecture-independent support files directory])],
[pg_server_sharedir=${withval}])
AC_MSG_RESULT([$pg_server_sharedir])
AC_SUBST([pg_server_sharedir])
pg_contribdir=$pg_server_sharedir/contrib
AC_SUBST([pg_contribdir])
Why? Apart from a DESTDIR install, distcheck also tries to configure
and install the tree below some specific --prefix, and tries to ensure
that your package installs all files below $prefix. This is a
requirement from the GNU Coding Standards. See here for more
information:
Thanks. I remembered after I sent the mail that I'd actually come across
this limitation before, and I think brought it up on the list.
While I do agree that the GNU coding standards are correct in insisting
that all files are installed under $prefix, I do think that there are
valid situations where this ideal scenario does not make sense.
For example: gutenprint provides CUPS printer drivers (backends), which
*must* be installed under $(cups-config --serverbin) [/usr/lib/cups on
my system]. Installing under /prefix would be possible, but would be
completely useless (the CUPS server looks in one location only for
available backends). Currently, we do allow the user to override the
extra-prefix default location, so user installation is possible, but
not the default.
In this case, we are installing a PostgreSQL database extension, which
really needs the loadable modules installing in $(pg_config --pkglibdir)
[/usr/lib/postgresql/8.3/lib] on my system. This is by default the only
path searched for extensions, though it is possible to add alternative
locations.
I guess my point here is that for some packages, user installation is
simply not possible (at least for some components of the package).
For others, it is possible, but not ideal. I'm not sure exactly the
best way to default things in the configure script in the latter case.
Defaulting to strict GNU coding standards correctness isn't going to
be what most people would want.
Would it be possible to use *both* --prefix and $(DESTDIR) when
testing make install within make distcheck? This would provide
several advantages:
1) The installation won't just fail if it attempts to install into
a location outside $prefix. If the location *had* been writable,
it would still have succeeded had I run distcheck as root, for
example, so *success doesn't guarantee a non-buggy package*.
The uninstall check could even have removed files from the
system AFAICT.
2) You can now check $prefix inside the DESTDIR, and also look at
files installed outside $prefix but which are present in the
DESTDIR and report these as buggy to the user and error out,
which would help bring buggy Makefile.ams to the developer's
attention. This isn't currently done. It would also allow one
to add an automake option to not treat these files outside the
prefix as errors.
This would both make distcheck both more robust, and more flexible.
While for all but a few packages installing outside $prefix is
completely wrong, I think that it would be nice it automake
had the flexibility to allow it if given the option, but obviously
not the default!
One way to fix your code would be to check for whether the user has
overridden $prefix, $datarootdir, or $datadir, and in that case, let
pg_server_sharedir depend on the latter (the defaults for these
variables are NONE, '${prefix}/share', and '${datarootdir}',
respectively, with recent Autoconf versions). Another way to let
the distcheck pass (but still allow to annoy your users ;-)
is to add an appropriate --with-pg-server-sharedir to the make macro
Re: make distcheck fails for simple Makefile.am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger It's often the case that a package installs files in locations picked Roger up by configure. e.g. in gimp-print the CUPS PPD files get installed Roger in `cups-config --datadir`, and the drivers in `cups-config Roger --serverbin`/filter. 'make distcheck' has never worked because of Roger this. The FAQ entry `Hard-Coded Install Paths' has some suggestions. Thanks. I read this, but I still don't think this is the correct solution. I can see this would work well for a user-extensible program, such as the GIMP, which has system and user plugin and module directories. For system-level programs, there is only one install location. In the case of CUPS, the directories for data, backend binaries and filter binaries are fixed. Being able to specify an alternate location with configure is pointless: the locations specified with the -config script are the only useful locations on the system. Any other location will result in a non-functional program. In the case of programs using Linux-PAM (libpam), /etc/pam.d and /etc/security are the only places you could install authentication service configuration files. It doesn't make sense to have any other place for e.g. SSH configuration, and it would be a security issue to boot. Even if a user builds their own SSH, it will still need to look there, even if different --prefix options were used: the libpam library has this hardcoded for security. These are certainly rare cases, but it would be nice if automake could cater for them. I read distdir.am, and saw the comment: ## Make sure the package has proper DESTDIR support (we could not test this ## in the previous install/installcheck/uninstall test, because it's reasonable ## for installcheck to fail in a DESTDIR install). I can see the rationale here, but it would be nice to be able to do it all the same if requested (I haven't written any installcheck stuff, so it can't fail). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFCxmkNVcFcaSW/uEgRAl5vAKDl+fJI2ZasdI1+9S4hrlKzcMw4oQCdELcT 7lmmB1DgWR1CcwwYXwvJBqU= =30L2 -END PGP SIGNATURE-
Re: make distcheck fails for simple Makefile.am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Friesenhahn [EMAIL PROTECTED] writes: On Sat, 2 Jul 2005, Roger Leigh wrote: Thanks. I read this, but I still don't think this is the correct solution. I can see this would work well for a user-extensible program, such as the GIMP, which has system and user plugin and module directories. For system-level programs, there is only one install location. In the case of CUPS, the directories for data, backend binaries and filter binaries are fixed. Being able to specify an alternate location with In this case CUPS must be broken software. Fixed at install time is considerably different than hard coded in the source code. I was probably not clear. CUPS has a configure script, with which I can specify --prefix and whatever other configure options I like. For any given CUPS installation, there will therefore be a defined set of directories in which to install backend drivers, filter drivers and driver data. Because its a service, running as root/lpadmin, it is not user-extensible. The search path for extensions is fixed to a set of directories within its configured prefix, one per extension type (e.g. $prefix/share/cups/model and $exec_prefix/lib/cups/filter). My package is a CUPS _driver_, i.e. an extension. It asks CUPS (via cups-config) what those configure options were. It makes no sense for this to be a configure option in _my_ script: if it doesn't use the ones from CUPS, CUPS will not see my driver, because it installed in the wrong place. My package could be configured with a totally different prefix, and it will happily install its shared libraries, modules and data there, but the parts that bridge with CUPS must go where CUPS wants them. I hope I've made that clear. There are two separate packages, configured independently, but the second (mine) is dependent upon the first to a certain extent. My package is split into - - normal programs, libs and data. These live in the standard prefix - - interface programs and data. These go where configure detects they should go. You can specify via the CUPS_CONFIG variable which CUPS installation it should use, but the installation settings are extracted from cups-config. - - There are several interface parts, for other printing systems e.g. foomatic. This also relies on previously-installed binaries (foomatic-kitload) in order to install. This is again for the same reasons. - - In effect, my package is actually configured with several different prefixes, e.g. $prefix and $cups_prefix. The former is the the normal one, the latter from the cups-config script (though it's more complex than that--it picks out each separate directory rather than a general prefix). In the case of programs using Linux-PAM (libpam), /etc/pam.d and /etc/security are the only places you could install authentication service configuration files. It doesn't make sense to have any other place for e.g. SSH configuration, and it would be a security issue to boot. Even if a user builds their own SSH, it will still need to look Sorry, my SSH configuration files are not under /etc. There were good reasons to put them somewhere else (besides the fact that OpenSSH defaults to elsewhere). I don't see how relocating these files could be a security issue. You can configure ssh in several ways (it was just an example of a PAM-using service); I simply described the way it's done on Debian GNU/Linux. Perhaps you don't use PAM? The point was not about SSH, but about libpam. This can't be altered, and IMHO for good reasons, but we do need to be able to cope with it whether or not we like it. Putting sensitive files in non-default locations actually improves security. If /bin/sh could be moved, then system security would improve immensely, but unfortunately, it is inconvenient to move. There are very few programs on a Unix system that I would call system-level programs. Certainly the process with PID=0 and (possibly) 'init' fall into this category. Everything else is just application software. In fact, it should be possible to use an alternate program in the place of 'init'. One person's system-level program is another person's relocatable/replaceable application. This does not have any bearing on the actual problem with automake. It would be wrong to assume that the world is bound by Linux conventions. The examples have nothing to do with Linux. These were just examples of particular cases where I found automake breaking. They may be atypical, but they are real. Whether we like it or not, automake-using packages do have to co-exist and interoperate with packages which might not do things as we would like. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail
Re: make distcheck fails for simple Makefile.am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues [EMAIL PROTECTED] writes: * Roger Leigh wrote on Sat, Jun 18, 2005 at 12:47:08PM CEST: In a simple Makefile.am: pamdir = /etc/pam.d pam_DATA = schroot EXTRA_DIST = $(pam_DATA) make distcheck fails: Make that pamdir = $(prefix)/etc/pam.d but you really should be using sysconfdir: pamdir = $(sysconfdir)/pam.d so that both the casual user and the distribution packager can easily override the values: the former could do configure --sysconfdir=/etc # rest goes under /usr/local whereas the latter does configure --prefix=/ In this case, it will always be /etc/pam.d. This directory is the location of the Linux-PAM service configuration files. For security, libpam won't look anywhere else. The package has other files to install in $(sysconfdir), so using $(sysconfdir) would be wrong because it's likely I might want that to be some other value. I /could/ do this, but I would likely need to override pamdir during 'make install' if it was wrong, which really defeats the point. If it only works when $(sysconfdir)=/etc, it's broken the rest of the time. So no, this is not a bug in Automake. IMO the ability to use literal absolute paths is unconventional, but sometimes required. If make distcheck used $(DESTDIR) rather than relying on the fact that *all* install paths begin with $(prefix), it would be rather more reliable. It's often the case that a package installs files in locations picked up by configure. e.g. in gimp-print the CUPS PPD files get installed in `cups-config --datadir`, and the drivers in `cups-config - --serverbin`/filter. 'make distcheck' has never worked because of this. In both of these cases, the location is dictated by packages already installed on the system. That location is completely independent of $(prefix). In summary: - - any location that does not start with $(prefix) will break distcheck - - this could be fixed by using $(DESTDIR) - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFCtogsVcFcaSW/uEgRAiKvAJ0ZGJTRKaR8jbdtSkmMQOgDLon4ggCghaWB H+2hTK+ctTD8HLujdPbKKzc= =KW8k -END PGP SIGNATURE-
make distcheck fails for simple Makefile.am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In a simple Makefile.am: pamdir = /etc/pam.d pam_DATA = schroot EXTRA_DIST = $(pam_DATA) make distcheck fails: make[4]: Entering directory `/home/rleigh/schroot/schroot-0.1.0/_build/schroot/pam' make[4]: Nothing to be done for `install-exec-am'. test -z /etc/pam.d || mkdir -p -- /etc/pam.d /usr/bin/install -c -m 644 '../../../schroot/pam/schroot' '/etc/pam.d/schroot' /usr/bin/install: cannot remove `/etc/pam.d/schroot': Permission denied make[4]: *** [install-pamDATA] Error 1 make[4]: Leaving directory `/home/rleigh/schroot/schroot-0.1.0/_build/schroot/pam' make[3]: *** [install-am] Error 2 Normal install, DESTDIR=$foo install, VPATH builds and DESTDIR installs OK too. This is automake 1.9.5 (on Debian). Could this be an automake bug? The source is here: http://people.debian.org/~rleigh/schroot-0.1.0.tar.bz2 (schroot/pam/Makefile.am). Many thanks, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFCs/upVcFcaSW/uEgRAtaEAJsGHdWUTk67My46m7jdOqs+vuM6zQCgpvOU jgYCWEMn+lXt6yi4LeqP/7s= =2/xO -END PGP SIGNATURE-
Re: configure-generated *.in's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stepan Kasal [EMAIL PROTECTED] writes: On Fri, Dec 31, 2004 at 03:09:21PM -0800, J.T. Conklin wrote: While AC_CONFIG_PKGCONFIG_IN() is very appealing, writing a script that takes similar arguments and generates a *.pc.in file that can if understand your situation correctly, you can still use AC_CONFIG_PKGCONFIG_IN to get the *.pc.in at configure time. You just cannot use AC_CONFIG_FILES to instantiate it. That used to work. It still does, if you create a dummy .in file to fool automake, IIRC. However, as the author of AC_CONFIG_PKGCONFIG_IN(), I'd just like to say that I stopped using it in favour of static .pc.in files a few years ago, in order to preserve my sanity ;-) It's far easier to substitute simple cflags, libs, version and requires stuff directly, and is rather more flexible and understandable. I don't think it gains you much other than added complexity and an ego-expanding monster-sized configure script (which is probably why I originally wrote it :) The main reason I wrote it was a drop in replacement for AC_CONFIG_LIBCONFIG_IN when I was transitioning Gimp-Print from gimpprint-config to pkg-config. It made sense there, but I'm not sure it's generally useful today. The variables it uses are rather complex: it's geared to shared and static sets of flags and package-internal and -external flags, something that pkg-config can't do (and probably shouldn't, though support for static linking would be nice). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFB2yWKVcFcaSW/uEgRAkYaAJ97WNDVfQpDIr2JvNDNFzDsl6eUjQCeOE1l CND4c67AIuXh+y0iN8jEc7M= =kFdc -END PGP SIGNATURE-
Re: Who write the gtk-2.0.m4 file?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stepan Kasal [EMAIL PROTECTED] writes: On Wed, Dec 29, 2004 at 02:23:07PM -0300, Jonathan Gonzalez V. wrote: I found this file in aclocal, but it is not licensed, someone knows who wrote these macros and how I can contact him? I want to know if the file is under public domain or if have a license. the file is part of gtk+, as any package manager on any decent GNU/Linux can tell you. The author is Owen Taylor. The gtk+ package in at http://cvs.gnome.org/viewcvs/gtk+/ As the file has no special license, I'd guess it is covered by LGPL, as the whole gtk+. If you want to base a new macro upon AM_PATH_GTK*, try AC_PATH_LIB: http://ac-archive.sourceforge.net/rleigh/ac_path_lib.html which is a generic version of the same (though heavily developed since!). You can easily wrap it with a custom macro that expands this with some specific arguments. It also has companion macros: http://ac-archive.sourceforge.net/rleigh/ac_config_libconfig_in.html http://ac-archive.sourceforge.net/rleigh/ac_config_pkgconfig_in.html to generate -config script and pkg-config templates, respectively. However... the world has since moved to pkg-config, making these obsolete (thank goodness--they were a nightmare to debug!). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFB0xvuVcFcaSW/uEgRAmxwAKCQIRYn1OGm2JP012gXUJmt7a++igCfR/FJ XzeUKGwY/2hCPoWd+Fw3FEY= =DjTN -END PGP SIGNATURE-
Re: Automake and new tar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Fredrik Kalager Schaller [EMAIL PROTECTED] writes: I have been unable to 'make dist' gnome-themes-extras on Fedora due to tar complaining: tar: gnome-themes-extras-0.8.0/Gorilla/icons/scalable/mimetypes/gnome- mime-application-vnd.sun.xml.impress.svg: file name is too long (max 99); not dumped I was told today that the problem is that the new tar actually follows the spec for the method that automake wants to use. So automake needs to be fixed to not use the -o option to tar. The current automake release (1.9.3) allows one to select the tar format to use. It conservatively defaults to the old v7 format, but you can select a more up-to-date format which supports longer filenames. For example, in one of my projects which has very long pathnames, I use AM_INIT_AUTOMAKE([1.9 tar-ustar]) to use POSIX tar. You could also use tar-pax to use the new POSIX PAX format (but this is rather new if you need to care about portability). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFBqKDpVcFcaSW/uEgRAkHrAJ9Gk/mkF7b0FJuUWiZGC1nF3+RvaACfSEN4 DW/wg8nDrfRm3QT3ABH8Sa8= =YQd4 -END PGP SIGNATURE-
Re: How to remove custom directory with maintainer-clean
Oliver B. Fischer [EMAIL PROTECTED] writes: Since doc is a generated directory I would like to be able to remove it with maintainer-clean. Unfortunately adding doc to MAINTAINERCLEANFILES doesn't help, since the generated makefile tries to remove doc by executing rm -f doc. maintainer-clean-local: $(RM) -r doc HTH, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Makefile.am for GNU ed
John Poltorak [EMAIL PROTECTED] writes: On Sat, Apr 24, 2004 at 04:06:50PM -0500, Stephen Torri wrote: On Sat, 2004-04-24 at 15:21, John Poltorak wrote: I've never written a Makefile.am file but would like to have a try... GNU ed seems like a relatively simple app, so I'd be interested in writing one for it. Can anyone suggest where I start? Create a simple app that prints out a string. See your favorite hello world code. Use automake and autoconf to build the program by creating a simple Makefile.am and a configure.in. I tried that once but it isn't very instructive when using libraries. I'm trying to retro-fit a Makefile.am into GNU ed for my own purposes but am unsure about how to handle libs... If I have seperate headers for a bin and a lib program should they all be included under noinst_HEADERS as in:- ? bin_SOURCES = bin_a.c bin_bf.c noinst_HEADERS = bin_a.h bin_b.h The headers in _SOURCES won't be installed. If they belong to the program, that's the place to put them. noinst_LIBRARIES = liblib.a or should noiinst_HEADERS be split between the bin and the lib? Assuming you have a binary and a library, I'd do this: bin_PROGRAMS = prog prog_SOURCES = \ foo.c \ foo.h \ bar.c \ bar.h prog_LDADD = proglib.a noinst_LIBRARIES = proglib.a proglib_a_SOURCES = \ liba.c \ liba.h \ libb.c \ libb.h If you're only using static libs, libtool isn't really required. There's no need to noinst_HEADERS at all (I only use it when there's a directory only containing headers i.e. they don't belong to any built object). It would be more helpful if you posted *exactly* what your requirements are. HTH, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: [Bug-tar] Re: AMTAR brokenness
Ralph Schleicher [EMAIL PROTECTED] writes: Roger Leigh [EMAIL PROTECTED] writes: I'm using the patch I posted. If and when anyone complains, I'll instruct them to build and install the latest GNU tar (or build it for them). I require the functionality for long pathnames, and I don't want to have to support broken tools. For my needs, 99 chars is not at all sufficient. Have you ever considered using 'cpio -H ustar' instead of tar? I didn't realise it supported generating tar files. For the cpio I have (GNU cpio version 2.5): ustar The POSIX.1 tar format. Also recognizes GNU tar archives, which are similar but not identical. How does this differ from tar --format=posix. Isn't the POSIX tar format for the current GNU tar now the same thing? -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: [Bug-tar] Re: AMTAR brokenness
Bob Friesenhahn [EMAIL PROTECTED] writes: Is there a reason to allow file names longer than 99 characters in a package? Clearly this is non-portable. Why not enforce a maximum file name length of 99 characters in Automake? I experience the breakage when using Doxygen to generate a reference manual from C++ code. Some of the filenames it generates are over 80 chars, due to using namespaces, and long classnames etc. If the path is called libfoobar-baz-12.32.44/doc/libfoobar-baz/html/., that's an extra 46 chars in the path. The 99 char limit has been comfortably exceeded, and I had no control over this! [There are options to produce mangled 8.3 names, but I want them to be human readable.] One way to enforce this is to use sed to truncate file names longer than 99 characters before passing them to tar so that tar complains/fails during 'make dist'. What if the truncated names already exist? You will then silently produce a broken archive. Better to do find . | wc -L to get an accurate figure, and then bail out. I'm using the patch I posted. If and when anyone complains, I'll instruct them to build and install the latest GNU tar (or build it for them). I require the functionality for long pathnames, and I don't want to have to support broken tools. For my needs, 99 chars is not at all sufficient. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
AMTAR brokenness
Recent versions of GNU tar correctly use the -o option. This breaks any project with path lengths 100. Previously GNU tar incorrectly produced a POSIX tar file with -o, but now it produces a crippled UNIX v7 tarfile. PR/414 has been filed against automake. A patch against automake 1.8.3 follows, which uses the correct --format=posix syntax. Both the current and patched forms do rely on GNU tar. A configure check to check for GNY tar might be better. Either way, GNU tar should *not* be given the -o option, since it causes horrible breakage. Regards, Roger --- /tmp/distdir.am 2004-04-01 12:32:29.0 +0100 +++ distdir.am 2004-04-01 12:30:26.0 +0100 @@ -238,19 +238,19 @@ GZIP_ENV = --best .PHONY: dist-gzip dist-gzip: distdir - $(AMTAR) chof - $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).tar.gz + $(AMTAR) chf - $(distdir) --format=posix | GZIP=$(GZIP_ENV) gzip -c $(distdir).tar.gz $(am__remove_distdir) ?BZIP2?DIST_ARCHIVES += $(distdir).tar.bz2 .PHONY: dist-bzip2 dist-bzip2: distdir - $(AMTAR) chof - $(distdir) | bzip2 -9 -c $(distdir).tar.bz2 + $(AMTAR) chf - $(distdir) --format=posix | bzip2 -9 -c $(distdir).tar.bz2 $(am__remove_distdir) ?COMPRESS?DIST_ARCHIVES += $(distdir).tar.Z .PHONY: dist-tarZ dist-tarZ: distdir - $(AMTAR) chof - $(distdir) | compress -c $(distdir).tar.Z + $(AMTAR) chf - $(distdir) --format=posix | compress -c $(distdir).tar.Z $(am__remove_distdir) ?SHAR?DIST_ARCHIVES += $(distdir).shar.gz @@ -281,9 +281,9 @@ .PHONY: dist dist-all dist dist-all: distdir -?GZIP? $(AMTAR) chof - $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).tar.gz -?BZIP2?$(AMTAR) chof - $(distdir) | bzip2 -9 -c $(distdir).tar.bz2 -?COMPRESS? $(AMTAR) chof - $(distdir) | compress -c $(distdir).tar.Z +?GZIP? $(AMTAR) chf - $(distdir) --format=posix | GZIP=$(GZIP_ENV) gzip -c $(distdir).tar.gz +?BZIP2?$(AMTAR) chf - $(distdir) --format=posix | bzip2 -9 -c $(distdir).tar.bz2 +?COMPRESS? $(AMTAR) chf - $(distdir) --format=posix | compress -c $(distdir).tar.Z ?SHAR? shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).shar.gz ?ZIP? -rm -f $(distdir).zip ?ZIP? zip -rq $(distdir).zip $(distdir) -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Generating sources
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Hi Alexandre! Roger Leigh wrote: | In a project, I am preprocessing the C++ source and headers. That is: | foo.ccg - foo.cc | foo.hg - foo.h | | Some custom m4 I wrote processes the files with some simple rules: | | $(top_builddir)/build/classgen.m4f: $(top_srcdir)/build/classgen.m4 | $(M4) -P -F $@ $^ $^ is not portable. Please forgive me if you are assuming GNU Make, but as Automake strives to produce portable Makefiles and many people unconsciously break this portability when writing custom rules, I don't want someone who read the archives to blindingly copy the above... No problem. In this case I've made GNU make as a requirement, since I have no means to do portability testing with non-GNU makes, so I don't have to worry about portability. However, some of your suggested alternatives are much more concise, so I'll doubtless convert to using them. | libfoo_la_post_sources = \ | $(addsuffix .cc,$(basename $(filter %.ccg,$(libfoo_la_pre_sources \ | $(addsuffix .h,$(basename $(filter %.hg,$(libfoo_la_pre_sources In POSIX words: libfoo_la_post_sources = $(libfoo_la_pre_sources:g=) Yes :-) I think this is a lot easier to understand!! | libfoo_la_SOURCES = \ | $(libfoo_la_pre_sources) \ | $(libfoo_la_post_sources) \ | bar.cc \ | bar.h \ | | If I touch foo.ccg, foo.cc is regenerated and foo.lo rebuilt. | However, if I touch foo.hg, foo.h is not rebuilt, which is causing | problems (I need to do a manual make foo.h every time I alter | foo.hg). One issue with this setup is that foo.h doesn't exist the first time you try to compile the *.cc files that include it, and as dependency information is not available yet make won't help. Hence you have type `make foo.h'. On the following runs, however, dependency information is there, so I'd expect foo.h to be rebuilt before anything that depends on it is compiled. It doesn't exactly correspond to you description, so maybe I'm missing something. This is exactly my problem. The `Built sources' section of the manual discusses the above problem at lengths, and offer several solutions. The more common is to use BUILT_SOURCES. Thanks. I've made the changes you suggested, and it did the trick. BUILT_SOURCES triggers the source generation prior to the actual compile. The POSIX inference rules look very handy too, but I've not had a chance to test them yet. Many thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Generating sources
In a project, I am preprocessing the C++ source and headers. That is: foo.ccg - foo.cc foo.hg - foo.h Some custom m4 I wrote processes the files with some simple rules: $(top_builddir)/build/classgen.m4f: $(top_srcdir)/build/classgen.m4 $(M4) -P -F $@ $^ %.cc: %.ccg $(top_builddir)/build/classgen.m4f $(M4) -P -R $(top_builddir)/build/classgen.m4f $ $@ %.h: %.hg $(top_builddir)/build/classgen.m4f $(M4) -P -R $(top_builddir)/build/classgen.m4f $ $@ Now the complex part ;-) If I have, in my Makefile.am: lib_LTLIBRARIES = libfoo.la libfoo_la_pre_sources = \ foo.ccg \ foo.hg \ libfoo_la_post_sources = \ $(addsuffix .cc,$(basename $(filter %.ccg,$(libfoo_la_pre_sources \ $(addsuffix .h,$(basename $(filter %.hg,$(libfoo_la_pre_sources libfoo_la_SOURCES = \ $(libfoo_la_pre_sources) \ $(libfoo_la_post_sources) \ bar.cc \ bar.h \ If I touch foo.ccg, foo.cc is regenerated and foo.lo rebuilt. However, if I touch foo.hg, foo.h is not rebuilt, which is causing problems (I need to do a manual make foo.h every time I alter foo.hg). How should I make this automatic? I thought the above rules would be sufficient, but it does not appear so. Many thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: How many packages use autotools?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Jendrissek [EMAIL PROTECTED] writes: I am wondering how widespread the use of the autotools is - particularly among projects that are *not* GNU or other Free Software, or even Open Source but not-quite Free. IOW how many in-house completely locked-up proprietary packages use them? It's probably a bit hard to tell, these packages being uber-secret and all. Any (gu)estimates? I use it in all my Free software packages. I also use it at work, for non-free commercial stuff. TBH, a lot of commercial software has archaic build processes, since there's not the same requirement for repeated building of source on multiple platforms--there's one build and the binaries are distributed. Therefore, on DOS many projects are built by hand or with batch files and on UNIX, a plain Makefile or shell script will often do. I'd guess it's used, but far, far less than for Free software. Free software, being distributed primarily as source, must build conveniently and quickly on any user's system. That's the main reason for using autoconf (and automake etc.). Personally, I've spent several hundred hours working on the gimp-print build infrastructure alone. For the stuff I do for work, the company doesn't care how it builds as long as they can supply a set of binaries to customers. In addition, commercial pressures mean that there simply isn't time to devote to such things--which is just one reason why Free software is so oftern of much better quality. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQE/c1vYVcFcaSW/uEgRAlkqAJ9r1SEjfl/D1OFh41IXITnmDXzEEQCg02Ri AGGzMvx9mzd5BsnHoUQTsxY= =syRd -END PGP SIGNATURE-
Re: Starting make in subdirectory rather than root
Stephen Torri [EMAIL PROTECTED] writes: On Mon, 2002-11-18 at 08:23, Earnie Boyd wrote: As long as the sub-project didn't have dependencies on the other parts, your sound developer should be able to configure, cd Z and make. You could even create a configure.ac for Z that would just configure that portion. If Z does have dependencies on other parts then make sure they're satisfiable via the generated makefile. Earnie. How would you make sure that dependencies on other parts are satisified? Just add a dependency on a relative filename, and a rule to make that subdir: bin_PROGRAMS = foo foo_SOURCES = bar.c foo_LDADD = $(top_builddir)/mylib/mylib.la $(top_builddir)/mylib/mylib.la: cd $(top_builddir)/mylib; \ make mylib -- Roger Leigh Liberty and Livelihood - Support the Countryside Alliance Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: proposal to fork the build-tools projects
Tom Lord [EMAIL PROTECTED] writes: Long-time automake readers already know I'm strongly against this sort of structuring. This yields Makefiles which are fragile and undependable. For instance, if you create a temporary file with a source-like name in the source tree, then the build fails. Conversely, using the opposite approach, if you add a source file, and fail to correctly update the makefile, the build fails. Big whoop. Just as fragile and undependable either way. This is a purely rhetorical line of analysis that admits no objective decision making. Globbing can inadvertently lead to unwanted files being compiled/distributed/deleted/whatever. If you accidentally delete a source file, make won't complain because it won't know. If you explicitly list the files, it ensures the dependencies will be correct. You want the build to be /consistent/, and globbing does not guaruantee consistency. The build should be identical on my machine, all my co-developers' machines and my users machines, whatever temporary files, copied files etc. are in the source tree, and whatever they deleted, either accidentally or on purpose. In these cases a list certainly isn't fragile, and is much more dependable than globbing. Having to keep the Makefile.am up-to-date is a very small price to pay for consistency. That's not to say globbing is never useful; it certainly is. However, it does cause more problems than it solves. Try working out why $random_user's build is failing when you can't predict what is actually happening. Regards, Roger -- Roger Leigh Liberty and Livelihood - Support the Countryside Alliance Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: autoreconf misses ltmain.sh
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: [...] Ralf http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html Ralf .. which seems to indicate that libtool is the culprit. Ralf = There doesn't exist any officially released version of libtool that Ralf is usable with autoconf-2.54 and automake-1.7 Not exactly: there is no release of Libtool that honors AC_CONFIG_AUX_DIR in configure.*ac*. It's sometime in January I sent the patch for that. Is there no chance of a bugfix release, given that the fix is trivial? If you use libtool and AC_CONFIG_AUX_DIR, you need to do ugly things like having a configure.in symlink for libtoolize to use. Ralf .. still nobody wanting to care to fix it? AFAICT it's fixed in CVS Libtool. And in Debian. -- Roger Leigh Liberty and Livelihood Support the Countryside Alliance www.march-info.org
Re: Bug in distcheck target?
Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
Roger == Roger Leigh [EMAIL PROTECTED] writes:
[...]
Roger However, this makes one very big assumption: every
Roger installation directory will use $prefix as the path
Roger prefix.
Yes. This way we make sure people can install the package with
--prefix=/usr, --prefix=/opt, --prefix ~/usr, or whatever.
You could use /both/ --prefix= and DESTDIR= to ensure that the package
works with --prefix and then still set DESTDIR so that rules that
don't (can't) use $(prefix) will still get installed into =inst. BTW,
setting DESTDIR could also ensure that the package also respects
DESTDIR, by making sure that no data is installed into $(prefix),
because $(prefix) will be $(DESTDIR)$(prefix). Packages that
inconsistently handle DESTDIR are really annoying, possibly because
people don't even realise it exists.
You could set dc_prefix_base=`$(am__cd) $(distdir)/=error pwd`
and use --prefix=$$dc_prefix_base and DESTDIR=$$dc_install_base:
--- am-distcheckThu Sep 19 21:54:37 2002
+++ am-distcheck.newThu Sep 19 22:04:19 2002
@@ -6,19 +6,25 @@
GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz | $(AMTAR) xf -
chmod -R a-w $(distdir); chmod a+w $(distdir)
mkdir $(distdir)/=build
+ mkdir $(distdir)/=error
mkdir $(distdir)/=inst
chmod a-w $(distdir)
+ dc_prefix_base=`$(am__cd) $(distdir)/=error pwd` \
dc_install_base=`$(am__cd) $(distdir)/=inst pwd` \
cd $(distdir)/=build \
- ../configure --srcdir=.. --prefix=$$dc_install_base \
+ ../configure --srcdir=.. --prefix=$$dc_prefix_base \
--with-included-gettext \
$(DISTCHECK_CONFIGURE_FLAGS) \
$(MAKE) $(AM_MAKEFLAGS) \
$(MAKE) $(AM_MAKEFLAGS) dvi \
$(MAKE) $(AM_MAKEFLAGS) check \
- $(MAKE) $(AM_MAKEFLAGS) install \
- $(MAKE) $(AM_MAKEFLAGS) installcheck \
- $(MAKE) $(AM_MAKEFLAGS) uninstall \
+ $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \
+ $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \
+ $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \
+ (test `find $$dc_prefix_base -type f -print | wc -l` -le 1 \
+ || { echo ERROR: files and directories not installed into DESTDIR: ; \
+ find $$dc_prefix_base -print ; \
+ exit 1; } 2 ) \
(test `find $$dc_install_base -type f -print | wc -l` -le 1 \
|| { echo ERROR: files left after uninstall: ; \
find $$dc_install_base -type f -print ; \
Roger This is usually the case, but not always. For example,
Roger in the gimp-print project, we build a CUPS driver. For
Roger this, the install path is obtained from cups-config,
How about you honor the user's flags, and just issue a warning
if it's different from the output of cups-config?
The user never gets a say. I have in my Makefile.am something like:
if BUILD_GIMP
gimp_plug_in_PROGRAMS = print
endif
and in configure.ac, I have a custom autoconf macro
STP_GIMP_PLUG_IN_DIR which extracts gimp_plug_indir from gimptool.
Another macro gets the foomatic data directory location, too.
I have a similar arrangement for CUPS, with the exception that
--enable-cups will accept a prefix as well as yes or no. cups-config
(if present) overrides the users preference, since its information is
definitive.
In all three cases, the path should never need to be set by the user,
and is something like cupsexec_filterdir = $(pkglibdir)/filter where
pkglibdir is `cups-config --datadir`. There is no way of tacking a
$prefix on to these, especially for the GIMP and foomatic data, where
it is /always/ automatic, and adding an override would only ever be
used with make distcheck, and I would rather not write more m4
(there's already 50 kB of my own custom macros) just to work around
automake.
Another idea is the have a --without-cups-config option that you
will set in DISTCHECK_CONFIGURE_FLAGS.
This is already possible--for cups, but it would require a separate
option for every other driver (CUPS is just one example).
[...]
Roger $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \
Roger $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \
Roger $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \
Unfortunately `make installcheck' isn't expected to run in a
DESTDIR installation as it might run programs which read files
using the real $prefix.
I have looked at the generated Makefile.ins under 1.5 and 1.6.3, and I
can't see installcheck being used (except empty rules/for recursion).
Surely any user who wrote an installcheck-local target could use
$(prefix) and $(DESTDIR)$(prefix) as required to distinguish between
the intended and actual destinations? If the programs being run will
/only/ run correctly in the configured prefix, then I would
Bug in distcheck target?
I recently found a bug in the distcheck target: dc_install_base=`$(am__cd) $(distdir)/=inst pwd` \ cd $(distdir)/=build \ ../configure --srcdir=.. --prefix=$$dc_install_base \ ^^ --with-included-gettext \ $(DISTCHECK_CONFIGURE_FLAGS) \ I don't know if this will be considered buggy behaviour. However, this makes one very big assumption: every installation directory will use $prefix as the path prefix. This is usually the case, but not always. For example, in the gimp-print project, we build a CUPS driver. For this, the install path is obtained from cups-config, because the CUPS package is completely independent. This path will never contain $prefix, and so make distcheck will always fail. Suggested fix: Even though in this case, setting $prefix will not work, a similar effect could be achieved by setting DESTDIR=$$dc_install_base when installing and uninstalling. Every installed object should respect DESTDIR, and so this would not break distcheck. Modifying the distcheck rule as follows, and removing the --prefix option works fine: $(MAKE) $(AM_MAKEFLAGS) install \ $(MAKE) $(AM_MAKEFLAGS) installcheck \ $(MAKE) $(AM_MAKEFLAGS) uninstall \ becomes $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base install \ $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base installcheck \ $(MAKE) $(AM_MAKEFLAGS) DESTDIR=$$dc_install_base uninstall \ My current workaround is a new configure option, --enable-non-native-install-prefix=PREFIX, which is blank by default. This is used in install-*-local to install into $(DESTDIR)$(non_native_install_prefix)$(installdir), but this is totally gross. Currently I test the build with make DESTDIR=/tmp/test install # check everything is installed make DESTDIR=/tmp/test uninstall # check everything is cleaned up due to distcheck not working. Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: aclocal.m4:768: required file `./ltmain.sh' not found
On Tue, Jun 04, 2002 at 11:53:24AM +0200, Kremp, Johannes wrote: i'm on aix 4.3 and using autoconf 2.53, automake 1.6.1 and libtool 1.4.2. i run aclocal, autoconf and then automake. automake brings folowing message: :/home/ekjo/rvstop automake --add-missing aclocal.m4:768: required file `./ltmain.sh' not found the autotools are installed in the same path. why doesn't automake make a link to ltmain.sh? Did you run libtoolize? -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers msg05392/pgp0.pgp Description: PGP signature
Re: aclocal.m4:768: required file `./ltmain.sh' not found
On Tue, Jun 04, 2002 at 01:27:41PM +0200, Kremp, Johannes wrote: i didn't run libtoolize. i have a bootstrap-file which i start to generate my Makefiles: aclocal autoconf automake -a configure in earlier versions of automake it was enough. when should i call libtoolize? Call it first. In my bootstrap/autogen.sh scripts (borrowed from Gnome), I do: gettextize --force --copy libtoolize --force --copy aclocal automake --add-missing --force-missing --gnu autoconf -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers msg05394/pgp0.pgp Description: PGP signature
Re: Automake spam since last night
Bruce Korb [EMAIL PROTECTED] writes: I'm usually pretty tolerant because I have decent filters and a DSL pipe, but this is extreme and needs to be stopped: [...] It's not just the automake list; I'm seeing this on bug-gnu-utils too. I'm not convinced that having the lists completely open is a good idea with the amount of spam nowadays. Only allowing subscribers to post (like on SourceForge) would stop virtually all spam, and anyone who wants to post justs needs to subscribe (like everyone who wants to recieve the list). IIRC all posts from non-subscribers are held and can be either rejected or accepted by the list admin. -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: Overriding of automake rules fails
Tom Tromey [EMAIL PROTECTED] writes: Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger In a Makefile.am, we provide our own mostlyclean-aminfo rule, Roger which is identical to the default except that the dvi and ps Roger files are not removed. However, whilst this works with GNU Roger make, Solaris make will still use the original rule, because it Roger is still in Makefile.in Roger Would it be possible not to include this rule if it is already Roger defined in Makefile.am? That's what is supposed to happen. Please submit a Gnats PR on this. I just realised was probably made with 1.4 (not by myself), so I'll recheck with 1.6x first. Thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: Overriding of automake rules fails
Tom Tromey [EMAIL PROTECTED] writes: Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger In a Makefile.am, we provide our own mostlyclean-aminfo rule, Roger which is identical to the default except that the dvi and ps Roger files are not removed. However, whilst this works with GNU Roger make, Solaris make will still use the original rule, because it Roger is still in Makefile.in Roger Would it be possible not to include this rule if it is already Roger defined in Makefile.am? That's what is supposed to happen. Please submit a Gnats PR on this. I have checked again with automake 1.5 and 1.6. This only occurs with automake 1.4, so it's not a big deal. Thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: Automake a case study
On Tue, Apr 23, 2002 at 12:24:59AM -0600, Calvin Arndt wrote: Project/Makefile.am SUBDIRS = project docsdir = $(datadir)/project/docs ^^^ use $(PACKAGE), it's more flexible docs_DATA = project/docs/* In older releases of automake, you would have to write a dist-hook rule to distribute docs_DATA. That's not good. It will break if you use CVS, or have any generated files in there. Why not add `docs' to SUBDIRS, and have a dedicated Makefile.am in there to build/install/distribute the docs? You can use something like: man_MANS = [manpages] htmldir = $(datadir)/$(PACKAGE)/doc/html html_DATA = [html files] textdir = $(datadir)/$(PACKAGE)/doc text_DATA = [text files] EXTRA_DIST = $(man_MANS) $(html_DATA) $(text_DATA) I put those .am's together myself! BUT it took me two months. Redhat did a great job writing that book but it's absolutely worthless. The book spends more than half of its breath talking about libtool libraries and 2/3 of whats left on autoconf and only lightly touches on automake. The examples for automake are poor. Have you tried looking at existing projects as examples? There are literally thouands to choose from. Books are useful, but getting experience by looking at what other have done, and why, will teach you more. Experiment with it and see what it can do, and (possibly) find the limitations. Linux is not just the reallm of college CS majors anymore! Was it ever? I'm a biologist (and free software programmer in my spare time) -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Overriding of automake rules fails
In a Makefile.am, we provide our own mostlyclean-aminfo rule, which is identical to the default except that the dvi and ps files are not removed. However, whilst this works with GNU make, Solaris make will still use the original rule, because it is still in Makefile.in Would it be possible not to include this rule if it is already defined in Makefile.am? Thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: maintainer mode
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Roger == Roger Leigh [EMAIL PROTECTED] writes: [...] Roger In the gimp-print source tree, there are a number of Roger files which we ship in the distributed tarball Roger pre-built. These are PDF and HTML versions of SGML Roger manuals and PostScript versions of Texinfo manuals. We Roger do not want an end-user to have to have these tools Roger installed. The SGML tools are notoriously fragile (they Roger are currently partly broken on my system!), and not all Roger systems will have a teTeX installation. Roger Maintainer mode is used to modify what is cleaned. If Roger maint-mode is not enabled, then the pre-built files will Roger never be cleaned. To some extent, this deviates from the conventions that Automake tries to help you follow. `make clean' and `make distclean' are not expected to clean a file which is distributed: one generally uses `make maintainer-clean' to clean files that requires maintainer tools. An AM_MAINTAINER_MODE-free project could simply have these PDF and HTML files listed in MAINTAINERCLEANFILES. In our case, `maintainer-clean' /will/ always clean them. It's just that normal maintainers (such as myself) /do/ want the docs cleaned by `clean', so that we don't have to use `maintainer-clean' and blow everything else away when we are hacking on the docs. Another approach would be to check for the SGML tools in configure, define an AM_CONDITIONAL for this, and define your clean rule conditionally. We did do this originally. However, do to the problems that users with the tools reported, we decided to distribute the docs pre-built. (BTW, I think the following a bug in Automake: there are some files it always cleans for you, without wondering whether they are distributed or not. Unfortunately the postscripts built by the Texi rules are amongst them; so, somehow, it makes sense that you clean the PDF and HTML at the same time.) It would be nice if there was an easy way to do this (we had to redefine amostlyclean-aminfo' to stop the manual being cleaned). Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: maintainer mode
Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Warning: I'm going to give the AM_MAINTAINER_MODE is pure evil on a stick point of view. I know some people find it useful (although I don't know when). I'm sure the reasons you gave are valid (and I was not aware of some of the downsides you mentioned), but I thought I would demonstrate a valid use for it. In the gimp-print source tree, there are a number of files which we ship in the distributed tarball pre-built. These are PDF and HTML versions of SGML manuals and PostScript versions of Texinfo manuals. We do not want an end-user to have to have these tools installed. The SGML tools are notoriously fragile (they are currently partly broken on my system!), and not all systems will have a teTeX installation. Maintainer mode is used to modify what is cleaned. If maint-mode is not enabled, then the pre-built files will never be cleaned. If it is used, by users who explicitly enable it, then they will be removed. Doing this allows us to require only developers to have a greater set of tools to be installed and configured, without passing on the burden to our users. Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: RFC: ./configure or ./config.status --clean
On Wed, Apr 03, 2002 at 07:04:07PM +0200, Akim Demaille wrote: | Akim Demaille writes: | What I'm doing now is buying my freedom. The freedom to extend | Autoconf without 1. requiring from the rest of the world that they | adjust their distclean rules, 2. requiring that Automake folks release | a newer Automake etc., not to mention that it needs 1. writing | documentation, 2. telling the people to read it. | | All of these are good goals, but there are at least three other ways to | achieve them: | | 1. _AC_EXTRA_CLEAN_FILES([configure.lineno autom4te.cache]) | |To be traced by automake. So you are throwing away the non Automake users, and you lose the ability to run ./configure --clean without Makefile (precisely after a distclean). Why can't you do this: %% AC_CONFIG_DISTCLEANFILES(FILES) %% Clean FILES AC_DEFUN([AC_CONFIG_DISTCLEANFILES], [ac_distcleanfiles=$ac_distcleanfiles $1 AC_SUBST(ac_distcleanfiles) ]) You need to add support to automake to add ac_distcleanfiles to the distclean target, but after that any macro can register files to be cleaned. You can also do the cleaning (optionally) in config.status, and in your own Makefile.ins--you won't be tied to automake. An additional macro for ac_maintainercleanfiles would be nice. A similar method could be used to tell automake what files to distribute, such as configure, configure.ac, config.h.in etc. that automake currently hard-codes. -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: RFC: ./configure or ./config.status --clean
On Tue, Apr 02, 2002 at 06:57:05PM +0200, Akim Demaille wrote: That's really my question. But does it really matter? I mean, it makes no sense at all the distclean a single directory, as anyway you need to rerun config.status to re-enable this directory. Of course, knowledgeable people will answer that ./config.status foo/Makefile does it all, but... The average user won't know this. Subsequent recursive targets called from the top-level will now fail due to the missing Makefile, so it seems of dubious value to me too. -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: configure.ac warnings abou missing files
On Sun, Mar 24, 2002 at 01:37:43PM -0700, Tom Tromey wrote: Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger When automake runs, I'm getting this: Roger Running automake --gnu ... Roger configure.ac: 704: required file `src/main/gimpprint-config.in' not found Roger configure.ac: 704: required file `src/main/gimpprint.pc.in' not found Roger The two files do not exist because they are generated by Roger configure, and then processed by config.status. Is there any Roger way to tell automake that these files are /supposed/ to be Roger missing? Not right now. Does config.status find these files in the build tree? That would surprise me. (Or more precisely it would be another autoconf change I haven't kept up with.) OTOH, if you're building the files in the source tree, isn't it incorrect to build them in configure? The files in question are created by configure itself with m4 macros that output customised shell script/.pc files. They contain @replaceme@ statements for substitution by config.status. They will always be present for config.status due to being created by configure. They are removed by distclean. I don't think this is common (or good?) practice, but allows generation of complex shell script as you can use m4 to make it at autoconf time using e.g. m4_shift and recursion to generate the template. I have also been trying to get m4 to generate m4 code, to embed in and then output from configure, but it got too messy! Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
configure.ac warnings abou missing files
When automake runs, I'm getting this: Running automake --gnu ... configure.ac: 704: required file `src/main/gimpprint-config.in' not found configure.ac: 704: required file `src/main/gimpprint.pc.in' not found The two files do not exist because they are generated by configure, and then processed by config.status. Is there any way to tell automake that these files are /supposed/ to be missing? Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: [patch] mkinstalldirs used conditionally
On Mon, Mar 11, 2002 at 03:34:56PM +0100, Akim Demaille wrote: IMHO, this is obfuscating the code. The real means (again, IMHO) to address this issue should be to use an install-sh which creates the directories and their parents when needed. That would be ideal. It simplifies the code, addresses your issue, and also guarantees that in the future, all such targets will behave as you suggest. True. It won't be compatible with a traditional BSD install though, AFAIK. Would you contribute the AC_PROG_INSTALL macro and install-sh updates? I will try to. If install creates the directories, mkinstalldirs will have to be removed from the automake rules. This will necessitate autoconf/make *only* using the install-sh included in the source, or else installdirs will not be created. Is this correct? I can update install-sh to create installdirs, but what should I do about other installs? If we don't use install-sh, how do we create directories? Can this use install-sh as a wrapper to call other installs? -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
[patch] mkinstalldirs used conditionally
/python.am --- automake/lib/am/python.am Fri Nov 9 16:25:03 2001 +++ automake-new/lib/am/python.am Sat Mar 2 00:39:31 2002 -29,7 +29,9 ?!EXEC?.PHONY install-data-am: install-%DIR%PYTHON install-%DIR%PYTHON: $(%DIR%_PYTHON) $(NORMAL_INSTALL) - $(mkinstalldirs) $(DESTDIR)$(%NDIR%dir) + if test -n '$(%DIR%_PYTHON)'; then \ + $(mkinstalldirs) $(DESTDIR)$(%NDIR%dir); \ + fi list='$(%DIR%_PYTHON)'; dlist=''; for p in $$list; do\ if test -f $(srcdir)/$$p; then \ ## Compute basename of source file. Unless this is a nobase_ target, we diff -urN automake/lib/am/scripts.am automake-new/lib/am/scripts.am --- automake/lib/am/scripts.am Mon Apr 9 15:23:09 2001 +++ automake-new/lib/am/scripts.am Fri Mar 1 23:26:36 2002 -28,7 +28,9 ?!EXEC?.PHONY install-data-am: install-%DIR%SCRIPTS install-%DIR%SCRIPTS: $(%DIR%_SCRIPTS) $(NORMAL_INSTALL) - $(mkinstalldirs) $(DESTDIR)$(%NDIR%dir) + if test -n '$(%DIR%_SCRIPTS)'; then \ + $(mkinstalldirs) $(DESTDIR)$(%NDIR%dir); \ + fi ## Funny invocation because Makefile variable can be empty, leading to ## a syntax error in sh. list='$(%DIR%_SCRIPTS)'; for p in $$list; do \ diff -urN automake/lib/am/texinfos.am automake-new/lib/am/texinfos.am --- automake/lib/am/texinfos.am Tue Oct 2 17:00:04 2001 +++ automake-new/lib/am/texinfos.am Fri Mar 1 23:26:36 2002 -106,7 +106,9 if %?LOCAL-TEXIS% install-info-am: $(INFO_DEPS) $(NORMAL_INSTALL) - $(mkinstalldirs) $(DESTDIR)$(infodir) + if test -n '$(INFO_DEPS)'; then \ + $(mkinstalldirs) $(DESTDIR)$(infodir); \ + fi list='$(INFO_DEPS)'; \ for file in $$list; do \ ?CYGNUS? if test -f $$file; then d=.; else d=$(srcdir); fi; \ -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
mkinstalldirs and conditional building/installation
In a Makefileam, I have the following (summary): pkglibdir = $(cups_conf_serverbin) cupsexec_filterdir = $(pkglibdir)/filter if BUILD_CUPS cupsexec_filter_PROGRAMS = rastertoprinter commandtoepson commandtocanon endif Thus, if --with-cups is given to configure, AM_CONDITIONAL is used to conditionally build some programs The generated rule for installation in Makefilein is this: install-cupsexec_filterPROGRAMS: $(cupsexec_filter_PROGRAMS) $(NORMAL_INSTALL) $(mkinstalldirs) $(DESTDIR)$(cupsexec_filterdir) list='$(cupsexec_filter_PROGRAMS)'; for p in $$list; do \ p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \ if test -f $$p \ || test -f $$p1 \ ; then \ f=`echo $$p1|sed '$(transform);s/$$/$(EXEEXT)/'`; \ echo $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) $$p $(DESTDIR)$(cupsexec_filterdir)/$$f; \ $(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install $(INSTALL_PROGRAM) $$p $(DESTDIR)$(cupsexec_filterdir)/$$f; \ else :; fi; \ done The installation directory $(DESTDIR)$(cupsexec_filterdir) will be created *whether or not any program is built*! This should be fairly easy to correct: $(mkinstalldirs) $(DESTDIR)$(cupsexec_filterdir) becomes: if test -n '$(cupsexec_filter_PROGRAMS)'; then \ $(mkinstalldirs) $(DESTDIR)$(cupsexec_filterdir) \ fi In the gimp-print project, due to the nature of the package, just about every part can be compiled conditionally, because you generally only want a driver for one printing system At the moment, every possible installation directory is created, leaving unused empty directories after installation I don't have a patch, but I can make one if you would like--do I just need to update the am files? Is automake CVS available anonymously? Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counterliorg ** Need Epson Stylus Utilities? http://gimp-printsourceforgenet/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: mkinstalldirs and conditional building/installation
On Thu, Feb 28, 2002 at 11:38:11PM +, Roger Leigh wrote: Is automake CVS available anonymously? Sorry for being lame--I found it on Savannah -- Roger Leigh ** Registration Number: 151826, http://counterliorg ** Need Epson Stylus Utilities? http://gimp-printsourceforgenet/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: Newbie: packaging executables with libraries, how to build?
On Fri, Feb 08, 2002 at 03:42:30PM -0700, Tom Tromey wrote: Typically if you're installing a library then you are using libtool. Not many people build static-only installed libraries. Given that, in src/exec/Makefile.am you'd write something like: bin_PROGRAMS = foo foo_SOURCES = ... foo_LDADD = ../lib/libstuff.la For automake 1.4, I used to need to add things like: foo_DEPENDENCIES = ../lib/libstuff.la ../lib/libstuff.la: cd .. ; \ $(MAKE) libstuff.la In a bigger tree, this way you can get just what is needed built without always needing to run make from the top level to build everything in sequence. I just read in the manual that DEPENDENCIES is automatically determined. Is this a change for 1.5? I didn't see this in NEWS, and I confess I get lost in the ChangeLog! Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: AM_CONDITIONAL and config.status
On Sat, Feb 02, 2002 at 11:07:15AM -0700, Tom Tromey wrote: Roger == Roger Leigh [EMAIL PROTECTED] writes: Roger in Makefile.in, is it safe to use this format in my own .in files (e.g. Roger po/POTFILES.in), or will the format used for the conditionals in .in Roger files change at a future date? What I need to do is have lines Roger conditionally included, as some are conditionally distributed. Conditionals don't work they way you seem to think they do. The @FOO_TRUE@ is rewritten to either `' (empty string) or `#' (make comment) by configure. No line is omitted from the generated Makefile. My recommendation is not to rely on the implementation of conditionals. It isn't something we have ever documented. We might actually change it at some point; for instance we might be able to get better performance from config.status if we change how conditionals are implemented. OK. Back to the drawing board ;-) I did actually get this working: @GIMP_SOURCE_FALSE@# CUPS sources @GIMP_SOURCE_FALSE@src/cups/genppd.c @GIMP_SOURCE_FALSE@# Foomatic-related sources @GIMP_SOURCE_FALSE@src/foomatic/printer_options.c == # CUPS sources src/cups/genppd.c # Foomatic-related sources src/foomatic/printer_options.c When GIMP_SOURCE is true, the lines are nicely commented out with '#'. I won't use this though ;-) Roger if COND Roger FOO Roger BAR Roger BAZ Roger else Roger BAD Roger endif I read this example but I don't understand how it differs from what we already do. Right now you can enclose all kinds of stuff in a single conditional. What you can't do is have a conditional that starts or ends in the middle of a rule or macro definition. OK. I though that in the past I could only have one line between if-endif or if-else or else-endif. That was quite some time ago though. automake.info only gives examples which use a single line. Roger Being able to use 'ifndef' would also be another nice addition, Roger or has this already been done (I possibly remember this being Roger mentioned). You can use `if !FOO'. Great. Many thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: automake warning using lib_LTLIBRARIES
On Sat, Jan 26, 2002 at 01:37:26PM +0100, Alexandre Duret-Lutz wrote: If Automake sees `dir_PRIMARY = fubar' it knows that it must output some rules to build `fubar', even if `dir_PRIMARY' is defined conditionally. However if it sees `dir_PRIMARY = @fubar@', Automake can't guess what `@fubar@' will be substituted with, and can't output any rule to build those unknown targets. That's where the `EXTRA_PRIMARY' helps: it list those targets for which Automake should output build rules. Now, you're right that with most primaries adding a superfluous EXTRA_PRIMARY shouldn't hurt, that's like telling twice to Automake you need building rules for the listed targets. *_LTLIBRARIES is different because in order to build the library you need to know where it will be installed (and pass the appropriate -rpath option to libtool). That means you can't install a library in two different places. From `foo_LTLIBRARIES = mumble.la' Automake knows that `mumble.la' will be installed in `$(foodir)'; but from `EXTRA_LTLIBRARIES = mumble.la' it cannot know where the `mumble.la' will be installed, it could be somewhere else (so this justifies the error message). In the latter case, you have to play some _LDADD trickery to add the right -rpath flag manually, as said in the Automake manual. Thanks, that really explains it well. I was using -rpath too, so found the error a bit confusing. Many thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers msg04463/pgp0.pgp Description: PGP signature
automake warning using lib_LTLIBRARIES
I'm getting this warning from automake: roger@whinlatter:~/gimp-print/newbuild$ automake automake: both `configure.ac' and `configure.in' present: ignoring `configure.in' automake: src/main/Makefile.am: `libgimpprint.la' is already going to be installed in `lib' I'm sure this is not my fault. I do not explicitly redefine libdir, and my Makefile.am looks sane. I'm using automake 1.5, and libtool 1.4.2a on Debian GNU/Linux. Is this a libtool issue? The Makefile.am follows. Sorry it's not shortened, but I don't want to cut out the cause of the problem. The '##Programs' section is the relevent one. BTW, just a suggestion. AM_CONDITIONAL only accepts one line for the if or else part. Would it be feasable to use multiple lines? automake could transform multiple lines into several if statements, or there may be a cleaner way. I sometimes wish make conditionals could also be used as well as automake conditionals. Regards, Roger ## $Id: Makefile.am,v 1.31 2001/12/21 01:52:19 rlk Exp $ ## Copyright (C) 2000 Roger Leigh ## ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by ## the Free Software Foundation; either version 2, or (at your option) ## any later version. ## ## This program is distributed in the hope that it will be useful, ## but WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ## GNU General Public License for more details. ## ## You should have received a copy of the GNU General Public License ## along with this program; if not, write to the Free Software ## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. ## Process this file with automake to produce Makefile.in. AUTOMAKE_OPTIONS = 1.4 gnu @SET_MAKE@ MAINT_CHARSET = latin1 ## Variables AM_CFLAGS = $(GNUCFLAGS) INCLUDES = @INCLUDES@ m4datadir = $(datadir)/aclocal pkgconfigdatadir = $(prefix)/lib/pkgconfig ## Programs if BUILD_LIBGIMPPRINT lib_LTLIBRARIES = libgimpprint.la endif if BUILD_LIBGIMPPRINT bin_SCRIPTS = gimpprint-config endif EXTRA_SCRIPTS = gimpprint-config EXTRA_LTLIBRARIES = libgimpprint.la libgimpprint_la_SOURCES = \ gimp-print-internal.h \ print-lexmark.c \ print-canon.c \ print-dither.c \ print-escp2.c \ print-escp2.h \ print-escp2-data.c \ print-pcl.c \ print-ps.c \ print-util.c \ print-color.c \ print-weave.c \ print-version.c \ print-dither-matrices.c \ print-dither.h \ quickmatrix257.h \ ran.367.179.h \ ran.509.131.h libgimpprint_la_LIBADD = $(GIMPPRINT_DEPLIBS) # Uncommment to build an unversioned library (version in soname) libgimpprint_la_LDFLAGS = -release $(GIMPPRINT_VERSION) -rpath $(libdir) # Uncomment to build a versioned library #libgimpprint_la_LDFLAGS = \ # -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ # -rpath $(libdir) ## Data if BUILD_LIBGIMPPRINT m4data_DATA = gimpprint.m4 endif if BUILD_LIBGIMPPRINT pkgconfigdata_DATA = gimpprint.pc endif ## Rules print-util.lo: print-printers.c $(srcdir)/print-util.c print-printers.c: ../printdef/printdef $(srcdir)/printers.xml ../printdef/printdef $(srcdir)/printers.xml print-printers.c printdefl.o: printdefy.o ../printdef/printdef: $(addprefix ../printdef/, printdefl.l printdefy.y printdef.h) cd ../printdef ; \ $(MAKE) ## Clean CLEANFILES = print-printers.c DISTCLEANFILES = gimpprint-config gimpprint-config.in gimpprint.pc gimpprint.pc.in gimpprint.m4 MAINTAINERCLEANFILES = Makefile.in EXTRA_DIST = gimpprint.m4.top gimpprint.m4.bot printers.xml -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers msg04452/pgp0.pgp Description: PGP signature
