On Sun, 2008-07-13 at 10:12 +0200, Michael Schwendt wrote:
> On Sat, 12 Jul 2008 20:10:51 -0400, Doug Ledford wrote:
>
> > > For other
> > > projects one cannot build from a scm checkout without running scripts,
> > > such as autogen.sh where one would need to reproduce the upstream
> > > development env.
> >
> > Where is the reference on that BTW. There was a time in the past when
> > someone asked me what they should do before generating their tarballs
> > and I told them to just tar it up and go, and I had every intention of
> > running autogen.sh myself during the build process. Then someone told
> > me "No, they need to run autogen.sh before they make the tarball". So,
> > why is that? Why shouldn't the sources be autogen'ed against our
> > specific dev environment, after all we will be the ones building our
> > rpms in our build environment, so it would seem to make sense to me.
> > Obviously I must be missing something of great importance...
>
> It's related to the reason why we have multiple auto{conf,make} versions
> in the distribution. You need to pick the set of tools that is compatible
> with the rest of the source build setup. Sometimes errors force you to run
> a specific older or newer(!) version than what you can choose from. Or
> errors make you patch the configure.{ac,in} and closely related files
> before you can set up the source at all. That alone may be quite some work
> for several projects. Further, there have been silent incompatibilities
> before, which break configuration of the source, because you generate a
> build environment which differs from upstream. The errors may be subtle,
> which aren't trivial to track down in thousands of generated lines of
> typical "configure" scripts or aclocal.m4 files. Or, what seems to autogen
> for you today breaks tomorrow in a completely unexpected and weird way,
> and at an unfortunate point of time, only because your upgraded autotools
> reveal a sleeping incompatibility.
OK, so to sum up, we have upstream run autogen.sh because the autogen
tools are buggy and from version to version they break. This then begs
the question of whether or not the autogen people should be kicked. It
also begs the question of how deeply a project depends on the autogen
tools. If a project only minorly depends on them to get some
definitions and the results barely effect the code, then it's possible,
and in fact likely, that they wouldn't get hit by the bugs you allude
to. So, in some cases, it would seem that running autogen.sh locally
might be OK given the risk of bug introduction is low.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
