xserver build failling AFTER it works ??

[Chuck Robey]

Daniel Stone wrote:

Might have sent this twice, I don't know, my mailer died in the first sending.

> On Sat, Jul 12, 2008 at 05:27:18PM -0400, Chuck Robey wrote:
>> it seems that, after it's built everything via the build.sh you so nicely
>> supply, the xserver build popr an error saying that make doesn't know how to
>> build ChangeLog.  I then try to build it lcoally in the xserver build (something
>> that normally works for testing) and the build simply completes normally.
>> That's obviously a problem of imprtance only later, after everything else works,
>> but it means that xserver never gets to the installation, unless I do that
>> manually afterwards, when it works fine.
> 
> Hmm, interesting.  Could I please get the output of make -d -v ChangeLog?

When I restart it from where it finished, it prints nothing whatever.  When I
start it from make, it finished the Xserver completely, fine.  When I try it
from the util/modular/build.sh, it finishes *nearly* (more maybe completely, i
don't know) the xserver, then gives me that error before starting any other
module.  I know, I have added (a while ago, maybe 2-3 months) a line into
build.sh that prints "Building $var1 Module $var2" with the obvious
replacements, so I know when it starts the next module, and here, it doesn't do
that.  I wish I could be more complete there.  it dies while building the cyrix
driver (see below).

I copied build.sh to build1.sh, and changed it (added #commenting) to make it
start right after xserver, and it starts building the drivers.  It doesn't
finish, it dies while doing the video drivers.  I have a error listing from
there, I cut the beginning off (it was 246K) and attached the much smaller piece
to this mail.

Like I said, it's doing driver/xf86-video-cyrix/src.

> 
>> You folks REALLY need a top level Makefile, one that manipulates the autogen
>> stuff, all that, correctly.  If anyone wanted that, I'm really rather good at
>> it.  Would you like something like that?  I'd need some questions answered ...
> 
> That's what build.sh is.  If this is insufficient for your needs, we'd
> happily point to your alternate version. :)

No, actually, it's not.  A correctly built make would scan it's list of
products, most especially their build times, and after comparing those build
times with the time stamps on the source files, only rebuild those items where
the sources are more newly modified than the products.  In other words, it's
intelligent about what it rebuilds.  Beyond that, as totally stupid as I am at
the auto-tools stuff, I'm really pretty good at make.  I think I would suggest
you use GNUmake, not the BSD make, since you're going to the gnu-derived
autotools (but the BSD makes are far better than m, but I could do either the
BSD make or the GNU make equally well.  I can also do their macros, so I could
make things pretty  intelligent, if you folks will give me the rules you want me
to follow in doing (or not doing) the build.

Another way to look at this is, your present tool rebuilds either everything, or
you need to manually tell it what directory to start from, then it rebuilds
everything from that point on.  Instead, I could have it inspect all of the
auto-tool derived files, and only do the autogen.sh stuff if needed, then do a
make that doesn't automatically clean and rebuild everything.  Rebuilding from
scratch is something that only folks who really don't understand building do ...
or, occaisonally, a developer gets their sources DO screwed up, that to have
faith, they want a distclean, but that's a rare thing, in a well designed system.

> 
>> Far as that goes, I still can't get the docs built, I don't know what tools to
>> use, or after that, the commandline to build them.  I *really* wish you folks
>> had used DocBook instead of LinuxDoc, DocBook is far better supported, a far
>> wider schema, and it's much better maintained, by a far larger audience.
> 
> I don't understand how a doc parser could ever be kernel-dependent, so
> you should be fine.  Have you tried?

Where did I say kernel dependent?  That would be a pretty silly item, and it's
not so, not so far as I know.  I just think that in choosing the Linucdoc to
compile your dics against (using their set of verbs), you're choosing a less
genrally supported toolset which is more strongly Linux-centric.  Tools to
format a Linuxdoc-formatted document DO exist, but they seem to be more complex,
harder to maintain, and you don't even have them in the code archive, do you?  I
couldn't find them.

There are things for DocBook that are more well-developed, and the DocBook tools
are far and away more generally well supported and the subject of a far greater
development audience.  And, theyu just happen to be less biased towards a single
OS.  Everybody seems to support DocBook.  Look, in fact, at the list of editors
that produce DocBook documentation directly, versus those that produce LinuxDoc
(if, in fact, you can find any).
> 
> Cheers,
> Daniel


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: build.out
URL: <http://lists.x.org/archives/xorg/attachments/20080712/6f2e3f80/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080712/6f2e3f80/attachment.pgp>