[Gluster-devel] Why not provide useful config.guess and config.sub in gluster's release tarball

[Zhengping Zhou]

    Actually, I think even if you pass all needed parameters to
./configure in current release tarball, the generated Makefile will
still be fault.Because whether you directly pass "--build" parameter
or generate it by config.guess, the "build" parameter in configure
still will be modified by config.sub.

    The code as follow:
    ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias`;
build=$ac_cv_build;  the $ac_build_alias is passing by parameter
"--build" or detected by config.guess,the $build which's value equals
the output of config.sub will provided to Makefile.

    So you have to run auto_gen.sh to generate new config.guess and
config.sub even if you passing all needed parameters to ./confiugre,
which means you must run auto_gen.sh in current release tarball, so
why not just remove the configure file or add a useful config.guess
and config.sub in the realease tarball

    Of course, we could add more error message to the output, but as
we known the configure's running will certainly be wrong whaterver you
passing to it , why we provide it to users in the tarball.

2017-04-05 16:10 GMT+08:00 Niels de Vos <ndevos at redhat.com>:
> 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 at redhat.com>:
>> > 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