groff
[Top][All Lists]
Advanced

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

Re: [Groff] : New groff preprocessor for Perl parts in groff files.


From: Ingo Schwarze
Subject: Re: [Groff] : New groff preprocessor for Perl parts in groff files.
Date: Mon, 10 Mar 2014 16:30:13 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Ralph,

Ralph Corderoy wrote on Mon, Mar 10, 2014 at 01:52:03PM +0000:
> Bernd Warken wrote:
>> Ingo wrote:

>>> I suspect this reordering might be a bad idea.  I realize you are
>>> trying to make this nicer by ordering it alphabetically, but i don't
>>> think the order is arbitrary.  I certainly remember dependency and
>>> ordering issues when porting groff in the past.

>> Ordering is 'logical' ("Spock").

> As is topological ordering by dependency if that's what's need to make
> it work consistently.  :-)

In a properly written Makefile, yes, sure, that would be the
canonical idea.

The groff build system, however, makes extensive use of recursive
make invocations, which kind of defeats the purpose of make,
in particular topological ordering by dependency.

In some places, tools built in one directory are required for
building stuff in other directories, but these directories are
in different sub-makes.  In some places, the build system relies
on the order of directories/files in list variables to enforce
the required build order.  If i remember correctly (and the comments
in the Makefile itself are correct), this is one of the places.
That is why i suspect breakage.

Since i don't quite understand Bernd's reply and i'm not quite sure
he is taking my hint seriously and actually looking into it, i'm
currently working on getting "make dist" going in my environment,
such that i can try a build from git as opposed to a build from a
release tarball.  I'm not quite there yet but will report back once
i have results.


Besides, enforcing build order by ordering directories/files
in list variables does not work at all in parallel builds.
I definitely know that this caused fallout in the past, even
before Bernd's commit, at exactly the place Bernd is now fiddling
with.  

So once i get my stuff going, expect a patch to Makefile.in
from me in any case.  It is broken either way, Bernd just made
it worse, i suspect.

Yours,
  Ingo



reply via email to

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