[Top][All Lists]

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


From: Raja R Harinath
Date: Wed, 26 Sep 2001 01:42:03 -0500
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.105


Jens Kr├╝ger <address@hidden> writes:

> Am Montag, 24. September 2001 17:08 schrieben Sie:
> > [snip]
>> You'll have to rewrite your configure script to generate all
>> directories _even_ if not all the features are used.
>> Automake tries to ensure that 'make dist' enters all directories and
>> copies all the files.  The generated package can later be configured
>> with different settings, after all.  So, all the directories and
>> Makefiles should exist, even if they're never invoked during some
>> builds.
> I had a look at the tar.gz file and I found all files needed for the
> distribution. I took this tarball, untar it, run configure with all possible
> options and packages and it works fine.

That tarball is the result of the first (outer) 'make dist', which
likely was run in your development tree.  It was likely generated from
a tree which had many/most/all of the options selected, so that all
directories existed in the build tree.  No wonder it has everything

(Even if the latest configure didn't have some options selected, your
tree may have had slightly stale makefiles left over from earlier
'configure's with different options, essentially leaving you with a
complete tree nonetheless.)

> My problem was and is that the make distcheck doesn't work. I have no
> possibility to run the configure script during make distcheck with any
>  option.
> In my opinion the reason is based on the 'make dist' call during make
> distcheck.

Obviously.  We know one 'make dist' succeeded, since it wouldn't have
created the '=build' directory otherwise.  It is the inner 'make
dist', the one inside the '=build' directory, that is failing.

> For me is there no reason to 'make dist' during 'make distcheck' or may you
> give me one?

Well, one reason is it's automake philosophy (or cussedness, if you
want it that way ;-).  Basically, you want the user of the
generated tarball to have all the privileges of a developer --
including the expectation that a 'make dist' in a default configured
build directory will generate a complete tarball with all features.

Another reason is that it is a great "debugging" feature.  It helps
you root out mistakes that you may have made w.r.t builddir, srcdir,
dist, nodist, BUILT_SOURCES and other issues.

It all boils down to this: the tarball generated by 'make dist' should
NOT depend on what flags you passed to 'configure' in the build tree
where you ran 'make dist' or 'make distcheck'.

- Hari
Raja R Harinath ------------------------------ address@hidden
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

reply via email to

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