On Wed, Apr 05, 2017 at 09:18:39AM +0800, Zhengping Zhou wrote:
> I have a test environment without internet connection. I'd like
> to build and install many packages from the tarball which downloaded
> from the official website.
> Generally, the tarball will provide a useful configure file, I
> mean which can generate the right makefile, or there will be no
> default configure file(only configure.ac),
> which means i should run auto_gen.sh to get configure.
> But it puzzles me that the tarball provides a configure file which
> cann't generate a right Makefile without any obvious error info. So
> why not just don't provide
> a configure file in the tarball, so the users will run auto_gen.sh to
> get one just like the developer in git environment.Or maybe you can
> provide a useful config.guess
> and config.sub in the tarball as I suggested in the last email.
Many of the distributions know that there are problems with the
provided config.{guess,sub} in tarballs. These distributions prevent
using them by overwriting the files automatically with their packaging
macros (like %configure in Fedora/CentOS), or passing all needed
parameters to ./configure because they already know for which
architecture to build.
Not all distributions like running ./autogen.sh upon building, because
that requires them to have additional tools in the build environment. It
is cleaner to provide ./configure in the tarball.
You are the first since the 3.8 release to report a problem with this. I
would prefer to keep the current behaviour, and improve the failure
reporting. The scripts that are placed in the tarball are found unders
the build-aux/ directory in the sources. These were intended to provide
clear error messages, maybe you have an idea how to improve them?
Thanks,
Niels
>
> Thanks,
> Zhengping
>
> 2017-04-03 17:05 GMT+08:00 Niels de Vos <ndevos@xxxxxxxxxx>:
> > On Sun, Apr 02, 2017 at 04:58:38PM +0800, Zhengping Zhou wrote:
> >> I have encountered a problem while trying to compile the
> >> release source tarball as usual :./confiugre;make;make install.
> >> It seems the Makefile generated by configure is not right and
> >> without any obvious error message.(Actually there are several
> >> warnings, such like "configure: WARNING: cache variable
> >> ac_cv_build contains a newline")
> >> I found the parameters "host" and "build" in Makefile
> >> which should passed by user or detected by config.guess are
> >> wrong, because current config.guess in the release tarball
> >> doesn't work as its explain in its content.
> >> Maybe it is better not to provide default configure file in the
> >> release tarball directly, so the users will run ./autogen.sh to
> >> generate the right configure and config.guess.Or we can provide
> >> a useful config.guess as usual.
> >
> > There is a little more information about this in
> > http://review.gluster.org/14503, the related bug
> > https://bugzilla.redhat.com/1223937 and the 3.8 release notes at
> > https://github.com/gluster/glusterfs/blob/release-3.8/doc/release-notes/3.8.0.md#changes-to-building-from-the-release-tarball
> >
> > It mainly boils down to providing support for distributions that do
> > builds for uncommon/new architectures. Including a config.guess and
> > config.sub in the repository means that someone needs to track the
> > upstream for those files. We have proven to be very bad at this (see the
> > contents in the contrib/ directory). Not including those files is a much
> > safer approach. Many distributions do not rely on those files in any
> > case, because they replace the files or call configure with all possible
> > parameters.
> >
> > We do not expect users to build binaries from the tarball, but hope that
> > the version is made available by all distributions instead. Developers
> > can build directly from the git repository, and that should work fine
> > too.
> >
> > Could you explain your need to build binaries from the release tarball,
> > and why you can not use the packages provided by the distribution you
> > use?
> >
> > Thanks,
> > Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
