On Mon, 20 Sep 2010 11:17:51 -0600, Matt Dew <m...@osource.org> wrote:
> Would I be burned in effigy if I asked about: Yes. > 1) just moving the build system away from autotools to cmake cmake isn't nearly as flexible as autotools, and requires that cmake be present on the build system to build tarballs. Plus, it doesn't reduce the steps needed to build the system, just (purports) to make the maintenance of the build system easier. > 2) having Kconfig for Xorg like the linux kernel has Kconfig is all about optional bits of code, which we have a limited amount of (and most desktop users shouldn't be adjusting these anyway). Autotools is all about detecting system characteristics, which Kconfig (happily) doesn't have to deal with at all. > 3) auto generated nightly tarballs for all the modules Binary tarballs? Source tarballs? If the former, they wouldn't be useful for most people, the latter isn't significantly different from git clone && ./autogen.sh > 4) then pitching build.sh,x-jhbuild, and all the other 'official' > build scripts As you know, my goal is to reduce the number of modules needed to run 'current' code to a small enough number that almost any script would suffice. If we get the protocol headers merged together, then to build current X server bits, you'd need: 1) protocol headers 2) X server source 3) libdrm source 4) evdev source 5) synaptics source (maybe) 6) mesa source 7) video driver source It seems like reducing the length of this list is about the best thing we can do to help people get current bits on their machines. -- keith.pack...@intel.com
pgpa9k4fcIzfI.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel