xserver build failling AFTER it works ??

Chuck Robey chuckr at telenix.org
Sat Jul 12 19:31:06 PDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Hutterer wrote:
> On Sat, Jul 12, 2008 at 08:59:22PM -0400, Chuck Robey wrote:
> [...]
> 
>> Like I said, it's doing driver/xf86-video-cyrix/src.
> 
> the best thing is to comment out the line starting the cyrix driver build.
> this will get your build going and won't bother you too much (unless you need
> this driver). The next thing would be to file a bug against the cyrix driver.
> 
>>> 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.  
> 
> the modularisation resulted in a lot of independent components. you can
> rebuild (and release) one component without requiring the rebuild of any other
> components.
> this feature is both praised and criticised, but regardless of that it's what
> we have until somebody opts to fix it. I believe there are a number of
> alternative build scripts floating around, egbert had one at one point and
> pcpa too. Maybe others. And of course there is the jhbuild moduleset.
> 
> build.sh is simply a script that connects these independent  
> components to save you typing autogen.sh 100 times.

Why do you assume that modularization rules out the use of make?  From what I
see here, you use no modularization tools (no auto-tools) above the level of the
parent of xserver (I've hinted at least 4 times so far that I don't know what
name you folks give that dir, but I call it xorgsrc).  From what I see, you use
either shell or that jhbuild thing.  I don't know how jhbuild works anyhow, had
no luck  in finding a config file for it on the internet.  Why is it you assume
you can't use 'make' at that level, and still keep the modularization?

Make could be used just fine to control what modules get built or rebuilt,
configured or re-configured, at the top, way the heck better than build.sh does.

> 
>> 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.
> 
> the point of modularisation is that once you built it once, you really only
> need to re-build those modules that you changed.

Except, like I said, if you use that build.sh script, everything gets built &
rebuilt & re-rebuilt.  That build.sh script is what I am asking to replace.  NOT
get rid of modularization.

Why would you think that?

 so you can assume that if you
> do a code modification or a git pull, you have to do a make.
> with few exceptions, this worked fine for me for the last years.
>  
>> 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).
> 
> AFAIK, recent documentation efforts have used the docbook format. As usual,
> there isn't nearly enough work done in this area but the ML archives would
> probably spit out a discussion or two where docbook xml was listed as
> preferred format.
> 

I got told to go read the DESIGN.sgml, it's a recent one (the email said it was)
and so I assumed (maybe wrongly) that it represented the state of Xorg-art.  it
uses LinuxDoc.

> Cheers,
>    Peter
>  

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh5aOoACgkQz62J6PPcoOkHQgCffgmNWVhVw6xc7Ml431vGo0kM
nYsAn3vH9cng39ENJHty8az+sgD5lpzM
=i1wR
-----END PGP SIGNATURE-----



More information about the xorg mailing list