dead code in build.sh?

[Matt Dew]

On Mon, Sep 20, 2010 at 12:01 PM, Keith Packard <keithp at keithp.com> wrote:
> On Mon, 20 Sep 2010 11:17:51 -0600, Matt Dew <matt at osource.org> wrote:
>
>> Would I be burned in effigy if I asked about:
>
> Yes.

Sweet.  bring on the pitchforks.
>
>> 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.
>

Is all that flexibility needed?  Does it get used?  every package
checks for  things like 'size_t supported...yes'  and 'max length of
gcc command line parameters....65535'.   Are these things still
needed?
Anyone used cmake,  can you comment on this one?

>> 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.

It can also be used to just build certain things like 'I just want
these video drivers'.

>
>> 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

Why wouldn't the binary tarballs be useful?
What's the option for folks who just wanna grab something and try out
say a recent build of X without having to spend an hour compiling it
themselves?

>
>> 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.

Beyond merging the protocol headers, how else can that list be
shortened?  Each of those items looks pretty important.

Matt