automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AutoGen-5.6.2 w/o libxml2 build problem


From: Alexandre Duret-Lutz
Subject: Re: AutoGen-5.6.2 w/o libxml2 build problem
Date: Tue, 22 Jun 2004 00:07:21 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

Hi Bruce!

>>> "Bruce" == Bruce Korb <address@hidden> writes:

[...]
 Bruce> When you invoke, "make dist" I believe you are claiming
 Bruce> that you wish to construct a new distribution for some
 Bruce> distribution-related purpose.  If you merely wish to
 Bruce> verify that the parts that you can build are built
 Bruce> correctly, you would invoke, "make check".  If you are
 Bruce> making a distribution, then that distribution needs to
 Bruce> be verified that all parts of it are functional.  It
 Bruce> would be difficult to verify the functionality of ag2xml
 Bruce> if you do not have libxml2.  Therefore, I do not think
 Bruce> it is correct to try to do a "make dist" when all
 Bruce> components cannot be built.
[...]

I tend to disagree.  First, `make dist' is a *user* target and
I'd expect it to work even when some part of the tree is not
being built.  For instance a user might have fixed the package
locally, and will want to run `make dist' in order to carry his
fixed version to other hosts.  He may not care about the subpart
of the package that isn't build.  Second, there are cases where
it is simply not possible to build all directories: setup with
architecture-dependent directories come to mind.

You, as an upstream maintainer, may have a stronger policy when
doing releases.  That sounds very sensible.  You could do so
simply by writing your own dist target on top of the existing
one, and use it instead.  For instance

release:
if !WITH_LIBXML2
        echo "Distributions cannot be made with a partial build" >&2
        exit 1
endif
        $(MAKE) distcheck

Some people also like to attach extra tests to `distcheck' using
`distcheck-hook'.  Jim does this a lot in Coreutils.  It's not
really clear to me when this is good.  Although `distcheck' is
not a GNU standard target like `dist', I tent to think of it as
user target too.  For instance I like to test new releases of
Automake on Coreutils, and some versions ago I could not do it
because Coreutils' `make distcheck' relied on some custom
non-distributed scripts.  This was annoying.  Requiring a
directory that I cannot build would be annoying too.  My feeling
is that extra tests added to dist or distcheck should be skipped
when they cannot be run (missing scripts, unbuilt directories,
...), and stricter policies (like the full build enforcement
above) should be implemented as separate maintainer targets.
Allowing users to test their changes even partially sounds
certainly better than disallowing them to test their changes at
all...  (And I for one prefer to receive a patch that has been
tested with `make distcheck' rather than with just `make
check'.)


Regarding the SUBDIRS/DIST_SUBDIRS definitions, I recommend
avoiding AC_SUBSTing directories in SUBDIRS, and using
AM_CONDITIONALs instead.  That way Automake can define
DIST_SUBDIRS correctly itself.  (Correctly means DIST_SUBDIRS
will include all directories that can possibly appear in
SUBDIRS.)  See node `Top level' in the manual for a discussion
about conditional subdirectories.
-- 
Alexandre Duret-Lutz





reply via email to

[Prev in Thread] Current Thread [Next in Thread]