xserver build failling AFTER it works ??

Chuck Robey chuckr at telenix.org
Sun Jul 13 09:45:38 PDT 2008


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

Daniel Stone wrote:
> On Sun, Jul 13, 2008 at 10:51:55AM -0400, Chuck Robey wrote:
>> Peter Hutterer wrote:
>>> 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).
> 
> Yeah, it sucks that that can happen on a make clean.  If you want to
> avoid this, pass --disable-maintainer-mode, but that means that you'll
> have to re-run autogen.sh every time you change configure.ac or a
> Makefile.  The default from the git tree (not sure if it is in the
> tarballs or not) is to rebuild these things _automatically_, which can
> cause annoying spurious builds or distclean failure.
> 
> OTOH, it prevents the million annoying situations where you forget to
> run autogen.sh after you change the build system, and wonder why it
> isn't working, so. :)

True.  Maybe now you understand why I want to add a top level Makefile?  It
fixes all the downsides without requiring any changes to what's there now, not
changing it a micron.  BUT until I know how to do the autogen.sh stuff at least
once (and I need to know the names every every file that the autogen.sh regens,
not the resulting configure, just the autogen.sh stuff).  That's so I can
monitor the products of all those actions, and decide for myself when any
particular module needs re-genning.  It won't happen just to piss you off like
it does now.  If you touch one C file of one module, that's the only thing in
the entire tree that gets rebuilt, and if no autogen.sh is needed, none gets
done.  That, to me, sounds very attractive.  I can't understand why no one else
likes such a simple system, but then, I can't understand the auto-tools, so I
guess all things even out.

> 
>> 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..
> 
> As I've said, we'd certainly welcome and evaluate any patch.  No-one
> ever said we wouldn't: in fact, as we've repeatedly said, it's entirely
> the opposite.
> 
> We make sure build.sh always works.  Just because we don't say everyone
> should use it in every situation doesn't mean that we don't ensure it
> works, although not always optimally, because continuous rebuilding
> outside a distribution situation (where you have other tools to do this)
> is not something we optimise for.
> 
>> I said I couldn't do it without getting a question or two answered about th
>> 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.
> 
> Which questions in particular? If there've been any autotools questions
> I've missed, it's not because I'm ignoring them.  Somewhat culpable as I
> am, I try to make sure that I'm not neglecting it.
> 
> Cheers,
> Daniel

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

iEYEARECAAYFAkh6MTIACgkQz62J6PPcoOl0iwCffZP4qICI4sUn1CoH6BkSzj5r
rMsAn3ogPMMPl1jxrwaxB3wqg+CuGOtQ
=95dC
-----END PGP SIGNATURE-----



More information about the xorg mailing list