Subject: Re: "Monolithic" vs. "modular" build / was: Re: [Xorg] DocBook SGML/XML - msg#00020

List: freedesktop.release-wranglers

Date: Prev Next Index Thread: Prev Next Index

Roland Mainz writes:
> Keith Packard wrote:
> > > Erm... when was the decision made to introduce "autotool" stuff into the
> > > X.org tree (which implies SERIOUS legal questions when the Xorg tree
> > > starts to depend on non-X.org/MIT-licensed stuff) ?
> >
> > I guess I don't understand the problem here -- the tree won't contain any
> > non-MIT licensed material, and when ready for distribution won't require
> > any GPL licensed utilities to build. Yes, if you want to build from CVS,
> > you'll have to get automake, autoconf and libtool installed, or build
> > compatible systems.
>
> What if someone wants to build an OS which is completely free of GPL
> stuff ? Right now it's possible (and mandatory for some commercial
> vendors) ... but after the modularisation it will be unavoidable to use
> GPL-licensed tools to build the tree. That's not a problem for
> OpenSource OSes like Linux... but what about the commercial vendors ?

You should still be able to build the stuff as none of the stuff you
need to do the build should be under the GPL (at least not under the
GPL soleley). Only when you do development and need to extend the build
environment you will need GPLed tools.
However I'm not aware of any case where this is really an issue.

......

> options were used. And the people who are qualified to build Mozilla
> dropped significantly... it's now something like "black magic" to get a
> working Mozilla binary without shooting yourself into the feet with the
> wrong "configure" options. All these "issues" thanks to the "superiour"
> autotools stuff... fun... ;-(((((

I have deleted some of your comments to reduce the size of this email.
I have raised several of these points and was promised they can all
be dealt with. Now it is upon those who push for autotooling to proove
it.

>
> > Egbert has asked that I not push to remove the imake-based build system
> > any time soon, so if you really want to, you can continue building the

For the reasons you have mentioned. I don't want this to be
a one way road and I want to keep Imake around as long as people
have agreed that the new build system provides a workable solution
for them.
It took long nightly sessions at the bar to get that far ;-)

Cheers,
Egbert.

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Xanax (Pharmacia)1mg 90 Tabs SPECIAL !!! ))) gzlcjycqxv zunfbgc

CHEAP CHEAP CHEAP CHEAP BUY XANAX VALIUM VICODIN Plus Many More at super low prices! Click here to secure order now http://www.offerindex.com/qog345/104/ * World Wide Shipping! * No Doctors Will Visit! * Orders Shipped Same Day! * Free Fedex Shipping! Click here to secure order now http://www.offerindex.com/qog345/104/ NO Thanks http://www.offerindex.com/qog/pr/rf.html zk brc mzjfvjepum xhyuszmalih c _______________________________________________ release-wranglers mailing list release-wranglers-CC+yJ3UmIYqDUpFQwHEjaQ@xxxxxxxxxxxxxxxx http://freedesktop.org/mailman/listinfo/release-wranglers

Next Message by Date: click to view message preview

Re: [Xorg] DocBook SGML/XML manual pages...

Keith Packard writes: > > Around 0 o'clock on May 6, Roland Mainz wrote: > > > Does anyone know if there is already a way to handle Unix manual pages > > in DocBook/{SGML|XML} format ? There are now a couple of DocBook manual > > pages in the tree and I'd like to add more, but IMHO we need some > > official way to handle such stuff then... > > I don't think there are imake rules to handle docbook files. However, we > should start incorporating the autotool build files into the X.Org tree, > and we should certainly find a way to deal with docbook files in that > environment. > > Egbert suggested that perhaps we might like to create a common set of > autotool macros for us to share across multiple modules; perhaps rules for > docbook would be a good candidate for inclusion in that module. > That is certainly true. And it will convince me that we will not loose a feature that I found very importand in Imake ;-) However we should also proceed with our discussions about a future documentation standard. If we add files now and agree on a different standard in the future we will have to do more conversions than we already have to do now. Egbert.

Previous Message by Thread: click to view message preview

Re: "Monolithic" vs. "modular" build / was: Re: [Xorg] DocBook SGML/XML manual pages...

Roland Mainz wrote: I am not sure whether a "modular build" is something Xorg really wants. Other projects tried to split itself into "modules" and FAILED HORRIBLY with that (even mozilla.org tries to avoid adding such complex dependicies - right now all products (Mozilla/Seamonkey, FireFox, ThunderBird, SunBird, etc.) are build from ONE tree, even NSPR (Netscape Portable Runtime library), libPNG, libJPEG, etc are part of the tree). The release management and syncronisation between the single parts will be much more difficult and you have to deal with the interactions between the modules. Did anyone actually thought about the consequences of introducing a "modular" build ? And a modular build will requires a very well working project management (and I think Xorg is currently still far away from having a similar good communication tools as Mozilla.org had during the Netscape times) ... and if different people owning different modules disagree with some decisions all hell will break loose. There has been great debate here, and it's obvious a modular breakup of the tree can only work if all modules are "owned" by people who can work together. Presumably all modules will remain under the control of X.Org so that conflicts can be resolved by the Architecture Group, and failing that, the X.Org Board. Splitting some things out into separate modules is trivial (most of the client apps, many of the libraries) - but splitting out the core (server, libX11, libXext, libfont) is where it gets hard, especially with all the cross-dependencies and having to keep the protocols/headers in sync between the client and server sides. Autotools have the disadvantage of being a PAIN if you have many build options. And right now the Xorg tree has a few hundred build options. How do you want to deal with that ? Pass everything as arguments to "configure" or what ? The Mozilla "configure" script does that... which results very often in broken builds or confusion about which "configure" options were used. And the people who are qualified to build Mozilla dropped significantly... it's now something like "black magic" to get a working Mozilla binary without shooting yourself into the feet with the wrong "configure" options. All these "issues" thanks to the "superiour" autotools stuff... fun... ;-((((( The biggest advantage I see to autotools over imake is simplifying some of the configuration logic - it looks like many of the current build problems in X11R6.7.0 & the CVS head are caused by people not having the version of freetype installed that the static imake configuration expects for their OS. With autotools we could detect at build time if the external dependencies are correctly met - though that could be something as simple as having a configure script generate xc/config/cf/autoconf-settings.cf for imake. -- -Alan Coopersmith- alan.coopersmith-xsfywfwIY+M@xxxxxxxxxxxxxxxx Sun Microsystems, Inc. - X Window System Engineering

Next Message by Thread: click to view message preview

Loading Comments...