modular -> monolithic

[Egbert Eich]

Matthias Hopf writes:
 > 
 > Here I agree *very* much with you.
 > But how do you do that? I think a tinderbox-like build system would
 > improve the situation a lot here, though a lot of statements about the
 > quality of tinderbox itself have been stated on this list.
 > 
 > Having a monolithic build system doesn't necessarily change this. Those
 > developers who don't believe in thorough API build tests won't
 > necessarily build all drivers in the monolithic tree as well.
 > 

Tinderbox is not needed for this. It is good for playing the blame game
which may help changing people's mind set.
Once the Xsever is build (and that's the case for everyone who breaks
the API) it is trivial to build all drivers.
It shoudn't require more than 10 lines of shell script to do that
(plus 80+ lines for the list of drivers).
Yes, configure takes it's time, but with a little bit of additional
logic in the build script this can be reduced by caching the information.

I don't think it would be too much to ask from people who do significant
changes to the server to run such a script before they push (accidental)
API breakages upstream.

For deliberate API breakages this boils down to: who gets to fix it.
Doing a monolithic server + drivers package would force the burdeon
upon whoever breaks it.
If this is what we want - fine. 
But it doesn't necessarily require a monolithic server + drivers 
package.

It is a *social* issues which we are trying fix with a *technical* 
solution.

By doing this we would be sacrificing all the things which were once
deemed as the great features of splitting off drivers from the rest.
(In fact - recalling the discussion from those days the drivers
were the first thing that people suggested to split off).


 > > And frankly, what you say isn't effectively how things actually
 > > work.  You do have to check out large chunks of the various GIT
 > > trees (and it's non-trivial to figure out the dependencies,
 > 
 > Sigh. On the fetch-and-build side we really have work to do. Maybe we
 > should check Egbert's solution again, I thought to remember that it even
 > checked out the necessary trees if told to.
 > This certainly has to be documented better. I'm not pointing to anyone
 > here, just considering the state.

Yes, by specifying one (or a list of) target package(s) to build it
can check out (or update) and build the packages including all the 
packages it depends on.
Of course one can just build checked out packages without updating
them.
One just requires the dependecy information which the tool can generate
(if one has all packages checked out already).
Acutally the idea was to keep the dependency information for HEAD 
in one package (xorg/util/modular for instance) so that not everyone
needs to generate it from scratch.


 > 
 > > and the build.sh script is out of date half of the time) in order
 > > to do X server development or even work on a single driver.  So
 > 
 > I do driver development on a daily basis, and I don't even work against
 > current git head. The SDK from the last release is working well enough
 > in most cases. This might not be the case for the intel driver, though.

Oh?

 > 
 > > And right now, since the mentality to not break the build does
 > > not exist, the only viable solution is to force it upon people
 > > by unmodularizing the tree.
 > 
 > Which doesn't solve a thing.
 > Sorry for being destructive (and not constructive), but I just don't see
 > what this would help. I also don't see a technical solution at all to
 > this IMHO social problem. A tinderbox like solution might help, though.
 > 

Indeed. It's a mindset issue. Trying to fix people's mind set by
introducing a technical solution which throws overboard technical
advantages of the present solution is broken IHMO.

Cheers,
	Egbert.