xserver build failling AFTER it works ??

[Chuck Robey]

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

Peter Hutterer wrote:
> On Sat, Jul 12, 2008 at 10:31:06PM -0400, Chuck Robey wrote:
>>> 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?  
> 
> I don't. I'm just stating that the components are independent (as of yet) and
> there is no official script other than build.sh or jhbuild.
> 
>> 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).
> 
> I don't think it has a name.
> 
>> 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?
> 
> Because said makefile is missing, that's about the only reason why. Hence
> daniel's hint that if you want to write one, we'll be happy to take it.
> 
> regarding jhbuild: http://www.x.org/wiki/JhBuildInstructions
> 
>> 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.
> 
> correct. we don't disagree here.
>  
>>> 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.
> 
> my point was that you only ever need to use build.sh once, and then you just
> make && make install the components you modify.

Maybe it's because of my usually extreme allergy to doing things that use the
auto-tools (like, rebuilding the Makefiles, running autogen.sh) ... if I do a
git-clean of a make distclean, it ends up requiring a re-gen of Makefiles, and I
don't understand the required variables (if you just run autogen.sh bare, it
screws up, I tried it several times).  Running build.sh takes forever, because
(naturally) sh by itself has no built-in method to detect dependencies, what to
rebuild, and it wasn't designed to be run inside lower level dirs like one of
the modules, as make was.

The comment about it being "no official script other than build.sh" strikes me
as funny ... something like asking a bank robber if they like stealing, and
having them answer "no, of course not ... well, excepting this robbery, of
course".  That's somewhat of an extreme simile, sorry, it's the only one that
ocurred to me at the moment.  I am talking about replacing build.sh, so saying
"we don't do that, except for build.sh" is just a bit on the droll side.  I
mean, I'm /talking/ /about/ replacing build.sh with a far better tool, one that
would be far simpler to fix if it got broken, and be able to do it without
making a single change in your modularization strategy..

I said I couldn't do it without getting a question or two answered about the
auto-tools part of the build, so both for that reason, and because I just
couldn't get myself to commit to your project without some approval, maybe I'll
just keep it private.  I'm going to have to wait until I see the answer to my
questions on these lists anyhow, and I figure that'll be a longish wait.  I'll
drop the topic, sorry.

> 
>>> 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.
> 
> uhm, no. looks like hasn't been touched in 2 years, and the last change before
> that was the import into X.org repos. Anyway, that doc is for writing new
> DDXs, mainly. 
> The protocol specs and a number of other things are in git/xorg/xorg-docs.
> But most of that is equally outdated...
> For input drivers (which I believe is you main work?), the only
> doc is other input drivers.

That seems to contradict some other stuff I got, but to be honest, if you're
using DocBook, then I don't really wish to push the topic anymore, I'm happy.  I
can pretty easily format the DocBook stuff.

>  
> Cheers,
>   Peter

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

iEYEARECAAYFAkh6FosACgkQz62J6PPcoOkmFACcD36FW8A0F7rBF/akST/fb3a6
dPcAniM+TRvBHOkDcBrWahuSNhdfNMc4
=R22+
-----END PGP SIGNATURE-----