automake
[Top][All Lists]
Advanced

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

Re: Comment on: FAQ chapter for the manual


From: Alexandre Duret-Lutz
Subject: Re: Comment on: FAQ chapter for the manual
Date: Fri, 07 Feb 2003 10:47:39 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

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

[...]

 Bruce> There's now a relatively simple process by which one can
 Bruce> delete reconstructed, but also distributed files.  I do
 Bruce> think it would be worthwhile to make that visible so that
 Bruce> those that do construct and distribute .texi files won't
 Bruce> have to necessarily tear their hair out.  Here's the magic:

 Bruce> distcleancheck_listfiles = \
 Bruce> find -type f -exec 'test -f $(srcdir)/{} || echo {} ;'

This is already documented.  I'm fine with adding an explicit
reference to this. "For desperate cases", I'd say, as I think
there is always better to do.

 Bruce> That will cause to be removed any file you both build and
 Bruce> redistribute.  Period.

To be less confusing, it's not "delete" nor "removed", but
"ignore" and "ignored".  (If you were meaning "removed from the
diagnostic" then we agree.)

[...]

 >> I just ship the .info files so that users to not need
 >> Texinfo.  And I ship the .texi files so that users do not need
 >> getdefs/autogen.

 Bruce> and if you have the .texi derivation rule as well, 

Of course I do.  They rules need to be here in case the user
changes something in the .texi dependencies.  This is a
requirement to achieve what Fran├žois Pinard would call a
dependable build.

 Bruce> then you need to either 1) be careful that "make
 Bruce> distcheck" doesn't construct the distributed file, 

I don't.  It simply doesn't happen.  There is no reason why it
should happen, expect if I, by error, had made these files
dependent on non-distributed built files like in the exemple I
present in the FAQ (or like you do in AutoGen), or if I forgot
to distribute a dependency.  These are two errors I could fix
easily, so I have no reason to hide them with
bla^H^H^Hdistcleancheck_listfiles magic.

I believe you have such dependencies in AutoGen: .texi files
that explicitely depends on binaries such as autogen or getdefs,
and are therefore always rebuilt.  

I believe that these dependencies unnecessarily trigger your
whole documentation pipe at make time, and that you then have to
play (too) many tricks in order not to suffer the consequences.

Have you tried getting rid of theses as in the help2man example?

foo.texi: built-build-tools sources
        build-command

becomes

foo.texi: sources
        $(MAKE) built-build-tools
        build-command

I believe fixing the dependencies at the root should allow to
distribute .c files, generated .texi files, and generated .info
files, without sourious rebuilds of the documentation.  With
clean rules and no pain.

Maybe I believe too much :).  Anyway, this is assuming you also
ship all dependencies (including @included .texi files, to be
clearer -- two mails ago I was under the impression you didn't
want to distribute them, as they were "trivially extracted", but
now you say you do distribute .texi files, so I'm confused).

[...]

 Bruce> It's ok to rebuild the .texi, not ok to choke because
 Bruce> they dont have texinfo or texi2html or whatever to go on.
 Bruce> In other words, I distribute the .texi and the .info and
 Bruce> I distribute the means for getting from .c to .texi.

I still would like to understand why you distribute generated
(.texi) files when it's ok to rebuild them.

I think there is no reason to rebuild a file which is
distributed.  That's what distcheckclean checks.  So I'd really
want to understand why you think differently (appart from giving
us occasions to talk, that is :)).  So far I've failed to get
your point.

BTW, autogen.info is not rebuilt the first time I run `make' in
Autogen (5.4.8), but it gets rebuilt if I run `make' a second
time.  Looks weird.  Is this intended?  I'm sorry I don't
understand why this happens.

Ciao,
-- 
Alexandre Duret-Lutz





reply via email to

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