Chicken/egg problem building from a 'git clone'

Chicken/egg problem building from a 'git clone'

[Joi Ellis]

I have an elderly laptop.  I can build and install git using a tarball.  I 
original installed git 1.6.0.  This evening I noticed 1.6.1 was availble, and I 
decided to try building from the git repository using 'git clone' as described 
in the git home page.   And to jump ahead of myself, I want to point out that 
1.6.1 will build from the tarball.  However...

The workspace I get using 'git clone' does not provide a configure file.  And 
because my laptop isn't running a bleeding edge distribution, my build tools 
are older than you'd expect, so...

"make all" fails becuase my libaries are old:

    LINK git-fast-import
fast-import.o: In function `store_object':
/usr/local/src/git/git/fast-import.c:1086: undefined reference to `deflateBound'
/usr/local/src/git/git/fast-import.c:1109: undefined reference to `deflateBound'

"make configure" fails because my autoconf is too old.

    GEN configure
Usage: autoconf [-h] [--help] [-m dir] [--macrodir=dir]
       [-l dir] [--localdir=dir] [--version] [template-file]
make: *** [configure] Error 1

This found an issue with the Makefile, because my autoconf is sooo old, it's 
puking on the configure target build command, in part:

  autoconf -o $@ $<+ && \

because this old autoconf doesn't have a -o parameter.  If I change the
Makefile to:

  autoconf $<+ >$@ && \

Then the error becomes
    GEN configure
FATAL ERROR: Autoconf version 2.59 or higher is required for this script
make: *** [configure] Error 2

which is closer to what you intended.  I'm not sure what difference it makes 
between specifying -o and simply letting it default.

Anyway, would it break anything to have a 'configure' script provided as part 
of the clone pull?  It's provided in the tarball, and if I copy the 1.6.1 
configure script into my git workspace and run it, it seems to build.  I'm just 
not sure I trust it to be up-to-date with the configure script you folks can 
generate with your modern build tools using 'make configure'.

I realize the configure script is technically a build target but not having it 
does cause this chicken-egg issue on older platforms.

Re: Chicken/egg problem building from a 'git clone'

[Johannes Schindelin]

Hi,

On Fri, 6 Feb 2009, Joi Ellis wrote:

> "make all" fails becuase my libaries are old:
> 
>     LINK git-fast-import
> fast-import.o: In function `store_object':
> /usr/local/src/git/git/fast-import.c:1086: undefined reference to `deflateBound'
> /usr/local/src/git/git/fast-import.c:1109: undefined reference to `deflateBound'

You need to install a newer libz.  (And this is not a chicken & egg 
problem.)

Ciao,
Dscho

Re: Chicken/egg problem building from a 'git clone'

[Björn Steinbrink]

On 2009.02.06 04:09:24 +0000, Joi Ellis wrote:
> "make all" fails becuase my libaries are old:
> 
>     LINK git-fast-import
> fast-import.o: In function `store_object':
> /usr/local/src/git/git/fast-import.c:1086: undefined reference to `deflateBound'
> /usr/local/src/git/git/fast-import.c:1109: undefined reference to `deflateBound'

You can define NO_DEFLATE_BOUND. That and a bunch of other things you
can control are documented within the Makefile. No need for configure.

Björn

Re: Chicken/egg problem building from a 'git clone'

[Joi Ellis]

On Fri, 6 Feb 2009, Johannes Schindelin wrote:

> Hi,
> 
> On Fri, 6 Feb 2009, Joi Ellis wrote:
> 
> > "make all" fails becuase my libaries are old:
> > 
> >     LINK git-fast-import
> > fast-import.o: In function `store_object':
> > /usr/local/src/git/git/fast-import.c:1086: undefined reference to `deflateBound'
> > /usr/local/src/git/git/fast-import.c:1109: undefined reference to `deflateBound'
> 
> You need to install a newer libz.  (And this is not a chicken & egg 
> problem.)

Yes, this *is* a chicken & egg problem.  As I said in my original post,
git will build on this machine if I have a configure script to run
first.  The configure script explicitly checks for the version of libz
and sets a DEFINE appropriately.  Because there is no configure script
provided, and because my autoconf is considered too old, I simply can't
start the build process because I can't generate the missing configure
script.

Other projects put the configure script into source control to avoid
exactly this issue.

-- 
Joi Ellis                    
gyles19@visi.com

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
           - Chris Johnson

Re: Chicken/egg problem building from a 'git clone'

[Miles Bader]

Joi Ellis <gyles19@visi.com> writes:
> Because there is no configure script provided, and because my autoconf
> is considered too old, I simply can't start the build process because
> I can't generate the missing configure script.

Er, why don't you upgrade to a less ancient version of autoconf...?

Autoconf 2.59 (which is what it seems to want) was released like 5 years ago!

-Miles

-- 
97% of everything is grunge

Re: Chicken/egg problem building from a 'git clone'

[Björn Steinbrink]

On 2009.02.05 22:45:13 -0600, Joi Ellis wrote:
> On Fri, 6 Feb 2009, Johannes Schindelin wrote:
> 
> > Hi,
> > 
> > On Fri, 6 Feb 2009, Joi Ellis wrote:
> > 
> > > "make all" fails becuase my libaries are old:
> > > 
> > >     LINK git-fast-import
> > > fast-import.o: In function `store_object':
> > > /usr/local/src/git/git/fast-import.c:1086: undefined reference to `deflateBound'
> > > /usr/local/src/git/git/fast-import.c:1109: undefined reference to `deflateBound'
> > 
> > You need to install a newer libz.  (And this is not a chicken & egg 
> > problem.)
> 
> Yes, this *is* a chicken & egg problem.

No, it's not. It would be one if you needed git to update your zlib or
autoconf. But you don't, so you could simply update zlib or autoconf.
There's no circular dependency. You can even just do "make
NO_DEFLATE_BOUND=1" and be done with it...

Björn

Re: Chicken/egg problem building from a 'git clone'

[Junio C Hamano]

Miles Bader <miles@gnu.org> writes:

> Joi Ellis <gyles19@visi.com> writes:
>> Because there is no configure script provided, and because my autoconf
>> is considered too old, I simply can't start the build process because
>> I can't generate the missing configure script.
>
> Er, why don't you upgrade to a less ancient version of autoconf...?

Please do not encourage the use of configure/autoconf unnecessarily.

Our Makefile is designed to be usable *without* configure, exactly because
configure/autoconf is often a maintenance (if not portability) nightmare.

Use of configure is tolerated, not encouraged.

Re: Chicken/egg problem building from a 'git clone'

[Miles Bader]

Junio C Hamano <gitster@pobox.com> writes:
>>> Because there is no configure script provided, and because my autoconf
>>> is considered too old, I simply can't start the build process because
>>> I can't generate the missing configure script.
>>
>> Er, why don't you upgrade to a less ancient version of autoconf...?
>
> Please do not encourage the use of configure/autoconf unnecessarily.

Huh?  I'm not "encouraging the use of configure/autoconf unnecessarily",
I'm encouraging the use of a non-obsolete version of autoconf, should he
wish to use it (and he's the one that brought it up, so...).

> Use of configure is tolerated, not encouraged.

You're certainly welcome to discourage people from using it, but I see
no reason to do so myself.

-miles

-- 
Joy, n. An emotion variously excited, but in its highest degree arising from
the contemplation of grief in another.

Re: Chicken/egg problem building from a 'git clone'

[Junio C Hamano]

Miles Bader <miles@gnu.org> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>>>> Because there is no configure script provided, and because my autoconf
>>>> is considered too old, I simply can't start the build process because
>>>> I can't generate the missing configure script.
>>>
>>> Er, why don't you upgrade to a less ancient version of autoconf...?
>>
>> Please do not encourage the use of configure/autoconf unnecessarily.
>
> Huh?  I'm not "encouraging the use of configure/autoconf unnecessarily",
> I'm encouraging the use of a non-obsolete version of autoconf, should he
> wish to use it (and he's the one that brought it up, so...).
>
>> Use of configure is tolerated, not encouraged.
>
> You're certainly welcome to discourage people from using it, but I see
> no reason to do so myself.

Hmm, after reading my message again, I did sound rather misleading to
solicit a response like that from a gnu person, so let me try again.

Please do not encourge use of configure/autoconf *in this project*.

Use of configure *in this project* is not encouraged, it is merely
tolerated.

You are of course welcome to use configure and autoconf yourself for your
own projects, not here, but that goes without saying, I would think.

Re: Chicken/egg problem building from a 'git clone'

[Miles Bader]

Junio C Hamano <gitster@pobox.com> writes:
> Hmm, after reading my message again, I did sound rather misleading to
> solicit a response like that from a gnu person, so let me try again.
>
> Please do not encourge use of configure/autoconf *in this project*.

Er ... I was not doing so.  I was saying that if one is going to use
autoconf with git, one should use a non-ancient version.

I don't think merely discussing autoconf+git without pejorative asides
is "encouraging use".

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: Chicken/egg problem building from a 'git clone'

[Junio C Hamano]

Miles Bader <miles@gnu.org> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>>
>> Please do not encourge use of configure/autoconf *in this project*.
>
> Er ... I was not doing so.  I was saying that if one is going to use
> autoconf with git, one should use a non-ancient version.

That is nice but the statement is only half-truth, and should be followed
by ", but why bother?  You do not even need to use configure to build
git, and insn is all here...".

Omitting that latter half and instead having him spend time to update
autoconf, which is not even needed, sounds like strongly encouraging its
use to me.

> I don't think merely discussing autoconf+git without pejorative asides
> is "encouraging use".

"You should use recent enough autoconf *if* you want to use configure, but
why bother?  You do not even need to use configure to build git, and here
is how..." does not say anything pejorative about autoconf, either, and it
is certainly not encouraging its use.

On the other hand, omitting "but why bother?" part is, and the reason is
not because it does not badmouth autoconf, but because use of autoconf is
non-essential in this project.

Re: Chicken/egg problem building from a 'git clone'

[Miles Bader]

Junio C Hamano <gitster@pobox.com> writes:
>> Er ... I was not doing so.  I was saying that if one is going to use
>> autoconf with git, one should use a non-ancient version.
>
> That is nice but the statement is only half-truth, and should be followed
> by ", but why bother?  You do not even need to use configure to build
> git, and insn is all here...".

You've got to be kidding...

-Miles

-- 
Freebooter, n. A conqueror in a small way of business, whose annexations lack
of the sanctifying merit of magnitude.

Re: Chicken/egg problem building from a 'git clone'

[Johannes Schindelin]

Hi,

On Thu, 5 Feb 2009, Joi Ellis wrote:

> On Fri, 6 Feb 2009, Johannes Schindelin wrote:
> 
> > On Fri, 6 Feb 2009, Joi Ellis wrote:
> > 
> > > "make all" fails becuase my libaries are old:
> > > 
> > >     LINK git-fast-import
> > > fast-import.o: In function `store_object':
> > > /usr/local/src/git/git/fast-import.c:1086: undefined reference to `deflateBound'
> > > /usr/local/src/git/git/fast-import.c:1109: undefined reference to `deflateBound'
> > 
> > You need to install a newer libz.  (And this is not a chicken & egg 
> > problem.)
> 
> Yes, this *is* a chicken & egg problem.

No it is _not_.

A chicken and egg problem would be if your problem would go away if Git 
compiled cleanly.  But it does not.

> As I said in my original post, git will build on this machine if I have 
> a configure script to run first.  The configure script explicitly checks 
> for the version of libz and sets a DEFINE appropriately.

So why don't you DEFINE the thing explicitely?  From reading the Makefile, 
it appears as if

	$ make NO_DEFLATE_BOUND=YesPlease

should make it compile.  Of course, the documentation in the first part of 
the Makefile could be better, maybe you have suggestions?

Hth,
Dscho

Re: Chicken/egg problem building from a 'git clone'

[Daniel Barkalow]

On Fri, 6 Feb 2009, Joi Ellis wrote:

> I have an elderly laptop.  I can build and install git using a tarball.  I 
> original installed git 1.6.0.  This evening I noticed 1.6.1 was availble, and I 
> decided to try building from the git repository using 'git clone' as described 
> in the git home page.   And to jump ahead of myself, I want to point out that 
> 1.6.1 will build from the tarball.  However...
> 
> The workspace I get using 'git clone' does not provide a configure file.  And 
> because my laptop isn't running a bleeding edge distribution, my build tools 
> are older than you'd expect, so...
> 
> "make all" fails becuase my libaries are old:
> 
>     LINK git-fast-import
> fast-import.o: In function `store_object':
> /usr/local/src/git/git/fast-import.c:1086: undefined reference to `deflateBound'
> /usr/local/src/git/git/fast-import.c:1109: undefined reference to `deflateBound'

What zlib version do you have? If your libraries are old enough, git's 
cache.h header file should effectively enable NO_DEFLATE_BOUND. Maybe you 
have skew between your header files and the libraries the linker finds by 
default? Or maybe we should consider any zlib without a version in the 
header file old enough not to have deflateBound()?

	-Daniel
*This .sig left intentionally blank*

Re: Chicken/egg problem building from a 'git clone'

[Jeff King]

On Fri, Feb 06, 2009 at 02:28:48AM -0800, Junio C Hamano wrote:

> > Er ... I was not doing so.  I was saying that if one is going to use
> > autoconf with git, one should use a non-ancient version.
> 
> That is nice but the statement is only half-truth, and should be followed
> by ", but why bother?  You do not even need to use configure to build
> git, and insn is all here...".

I can think of one obvious reason why one might bother with autoconf: he
knows that git builds using the configuration detected by autoconf, but
it does not without. So yes, he _can_ tweak the Makefile manually to get
git to build, but he doesn't necessarily know which knobs to tweak. And
autoconf does.

Now, in this case, it was only one tweak and other responders have
already pointed him in the right direction. So just making that tweak
manually is probably the sane thing to do in this situation.

But I wanted to point out that autoconf is not totally without value
here.  There are people who may want to build git from a clone but who
_don't_ want to spend time learning about every tweakable build knob or
about how much their platform sucks.

-Peff

Re: Chicken/egg problem building from a 'git clone'

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Now, in this case, it was only one tweak and other responders have
> already pointed him in the right direction. So just making that tweak
> manually is probably the sane thing to do in this situation.
>
> But I wanted to point out that autoconf is not totally without value
> here.

I am not saying something that strong, either.  If autoconf generated
configure works _for you_ without hassle, great.  Keep using it.

The original message that started this thread was what to do when it does
NOT work for you, and my point was in general it is much nicer to point at
the knob to tweak from the make invocation command line (or in config.mak)
than having you spend time on upgrade autoconf, generate configure and run
it.

Fanboys may say that autoconf generated configure is the greatest thing
since sliced bread.  But let's face it.  Honestly, the track record of
those people in keeping autoconf part in this project up-to-date has not
been all that great.  There are things that the generated configure file
does not detect nor configure correctly (we had --with-expat patch, and we
also saw "the trailing slash in template_dir definition in config.mak.in"
discussed fairly recently).  You are much better off tweaking known
peculiarity of your platform in config.mak, when configure does not work
out of box for you.

Re: Chicken/egg problem building from a 'git clone'

[Joi Ellis]

On Fri, 6 Feb 2009, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Now, in this case, it was only one tweak and other responders have
> > already pointed him in the right direction. So just making that tweak
> > manually is probably the sane thing to do in this situation.
> >
> > But I wanted to point out that autoconf is not totally without value
> > here.
> 
> I am not saying something that strong, either.  If autoconf generated
> configure works _for you_ without hassle, great.  Keep using it.
> 
> The original message that started this thread was what to do when it does
> NOT work for you, and my point was in general it is much nicer to point at
> the knob to tweak from the make invocation command line (or in config.mak)
> than having you spend time on upgrade autoconf, generate configure and run
> it.

Actually, guys, if you go back and re-read my original message, I was
pointing out that if you use a 'git clone' to get a build tree, THERE IS
NO CONFIGURE SCRIPT in the tree.

The problem is not that the configure script does not work.  I pointed
out in the first paragraph that the configure script in the TARBALL
works just fine.  What I pointed out is that the build tree DOES NOT
PROVIDE THE CONFIGURE SCRIPT.  All I asked you to do is to consider
adding the configure script to the repository so that it gets pushed out 
in a clone.

> Fanboys may say that autoconf generated configure is the greatest thing
> since sliced bread.  But let's face it.  Honestly, the track record of
> those people in keeping autoconf part in this project up-to-date has not
> been all that great.  There are things that the generated configure file
> does not detect nor configure correctly (we had --with-expat patch, and we
> also saw "the trailing slash in template_dir definition in config.mak.in"
> discussed fairly recently).  You are much better off tweaking known
> peculiarity of your platform in config.mak, when configure does not work
> out of box for you.

I've been building and installing multi-platform *nix software on
various flavors for two decades now.  "./configure && make && make install" has 
been the standard build process even before GNU.  The whole point of
autoconf/configure/make tools is to eliminate the need to manually tweak
makefiles so that software is easily portable between platforms. 

I got such a rash of SNOTTY messages from you folks, all directed to me
privately, that I nearly deleted git from my laptop altogether.  You can be
sure I will not bother attempting to build git from a clone ever again.
I took the time to debug and diagnose the build failures I was getting,
and I tried to politely pass it along in case anyone cares.

Clearly, you don't.  I shall not waste your or my time any further.

-- 
Joi Ellis                    
gyles19@visi.com

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
           - Chris Johnson

Re: Chicken/egg problem building from a 'git clone'

[Björn Steinbrink]

On 2009.03.01 09:56:46 -0600, Joi Ellis wrote:
> On Fri, 6 Feb 2009, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > > Now, in this case, it was only one tweak and other responders have
> > > already pointed him in the right direction. So just making that tweak
> > > manually is probably the sane thing to do in this situation.
> > >
> > > But I wanted to point out that autoconf is not totally without value
> > > here.
> > 
> > I am not saying something that strong, either.  If autoconf generated
> > configure works _for you_ without hassle, great.  Keep using it.
> > 
> > The original message that started this thread was what to do when it does
> > NOT work for you, and my point was in general it is much nicer to point at
> > the knob to tweak from the make invocation command line (or in config.mak)
> > than having you spend time on upgrade autoconf, generate configure and run
> > it.
> 
> Actually, guys, if you go back and re-read my original message, I was
> pointing out that if you use a 'git clone' to get a build tree, THERE IS
> NO CONFIGURE SCRIPT in the tree.

And Junio was talking about the Makefile not working for you. And btw,
if you want a real chicken/egg problem, go complaining to the autoconf
folks that the autoconf git repository has no configure script either.
And autoconf actually requires autoconf for bootstrapping AFAICT, while
git does not. I'm sure they'll be happy to explain to you why having a
generated configure script in the repo is not a good idea.

Björn

Re: Chicken/egg problem building from a 'git clone'

[Andreas Ericsson]

Joi Ellis wrote:
> On Fri, 6 Feb 2009, Junio C Hamano wrote:
> 
>> Jeff King <peff@peff.net> writes:
>>
>>> Now, in this case, it was only one tweak and other responders have
>>> already pointed him in the right direction. So just making that tweak
>>> manually is probably the sane thing to do in this situation.
>>>
>>> But I wanted to point out that autoconf is not totally without value
>>> here.
>> I am not saying something that strong, either.  If autoconf generated
>> configure works _for you_ without hassle, great.  Keep using it.
>>
>> The original message that started this thread was what to do when it does
>> NOT work for you, and my point was in general it is much nicer to point at
>> the knob to tweak from the make invocation command line (or in config.mak)
>> than having you spend time on upgrade autoconf, generate configure and run
>> it.
> 
> Actually, guys, if you go back and re-read my original message, I was
> pointing out that if you use a 'git clone' to get a build tree, THERE IS
> NO CONFIGURE SCRIPT in the tree.
> 
> The problem is not that the configure script does not work.  I pointed
> out in the first paragraph that the configure script in the TARBALL
> works just fine.  What I pointed out is that the build tree DOES NOT
> PROVIDE THE CONFIGURE SCRIPT.  All I asked you to do is to consider
> adding the configure script to the repository so that it gets pushed out 
> in a clone.
> 
>> Fanboys may say that autoconf generated configure is the greatest thing
>> since sliced bread.  But let's face it.  Honestly, the track record of
>> those people in keeping autoconf part in this project up-to-date has not
>> been all that great.  There are things that the generated configure file
>> does not detect nor configure correctly (we had --with-expat patch, and we
>> also saw "the trailing slash in template_dir definition in config.mak.in"
>> discussed fairly recently).  You are much better off tweaking known
>> peculiarity of your platform in config.mak, when configure does not work
>> out of box for you.
> 
> I've been building and installing multi-platform *nix software on
> various flavors for two decades now.  "./configure && make && make install" has 
> been the standard build process even before GNU.  The whole point of
> autoconf/configure/make tools is to eliminate the need to manually tweak
> makefiles so that software is easily portable between platforms. 
> 

./configure is a generated script. Including it in the repository is not
something many projects do, since one of the things developers will be
working on is to change how that file is generated. Including it in the
release tar-balls is something every project (that uses autoconf) does,
since those are aimed at end-users.

It has not been the standard since before GNU, as the GNU project was
started quite a long time (well over a decade) before autoconf's inception.

> I got such a rash of SNOTTY messages from you folks, all directed to me
> privately, that I nearly deleted git from my laptop altogether.

I guess you're referring to the "To: " and "Cc: " fields of the emails
you received containing your address. For this particular list, that's
part of how we do things. It's quite common on high-volume lists to do
that, as people would otherwise have to sift through *all* the mail on
the list to figure out which emails are replies to their own questions
or patches. Somewhere in the Cc list you will see git@vger.kernel.org,
I'm sure.

>  You can be
> sure I will not bother attempting to build git from a clone ever again.
> I took the time to debug and diagnose the build failures I was getting,
> and I tried to politely pass it along in case anyone cares.
> 

Thank you for that.

> Clearly, you don't.  I shall not waste your or my time any further.
> 

And again, thank you for that.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Chicken/egg problem building from a 'git clone'

[John Tapsell]

2009/3/5 Andreas Ericsson <ae@op5.se>:
> Joi Ellis wrote:
>>
>> On Fri, 6 Feb 2009, Junio C Hamano wrote:
>>
>>> Jeff King <peff@peff.net> writes:
>>>
>>>> Now, in this case, it was only one tweak and other responders have
>>>> already pointed him in the right direction. So just making that tweak
>>>> manually is probably the sane thing to do in this situation.
>>>>
>>>> But I wanted to point out that autoconf is not totally without value
>>>> here.
>>>
>>> I am not saying something that strong, either.  If autoconf generated
>>> configure works _for you_ without hassle, great.  Keep using it.
>>>
>>> The original message that started this thread was what to do when it does
>>> NOT work for you, and my point was in general it is much nicer to point
>>> at
>>> the knob to tweak from the make invocation command line (or in
>>> config.mak)
>>> than having you spend time on upgrade autoconf, generate configure and
>>> run
>>> it.
>>
>> Actually, guys, if you go back and re-read my original message, I was
>> pointing out that if you use a 'git clone' to get a build tree, THERE IS
>> NO CONFIGURE SCRIPT in the tree.
>>
>> The problem is not that the configure script does not work.  I pointed
>> out in the first paragraph that the configure script in the TARBALL
>> works just fine.  What I pointed out is that the build tree DOES NOT
>> PROVIDE THE CONFIGURE SCRIPT.  All I asked you to do is to consider
>> adding the configure script to the repository so that it gets pushed out
>> in a clone.
>>
>>> Fanboys may say that autoconf generated configure is the greatest thing
>>> since sliced bread.  But let's face it.  Honestly, the track record of
>>> those people in keeping autoconf part in this project up-to-date has not
>>> been all that great.  There are things that the generated configure file
>>> does not detect nor configure correctly (we had --with-expat patch, and
>>> we
>>> also saw "the trailing slash in template_dir definition in config.mak.in"
>>> discussed fairly recently).  You are much better off tweaking known
>>> peculiarity of your platform in config.mak, when configure does not work
>>> out of box for you.
>>
>> I've been building and installing multi-platform *nix software on
>> various flavors for two decades now.  "./configure && make && make
>> install" has been the standard build process even before GNU.  The whole
>> point of
>> autoconf/configure/make tools is to eliminate the need to manually tweak
>> makefiles so that software is easily portable between platforms.
>
> ./configure is a generated script. Including it in the repository is not
> something many projects do, since one of the things developers will be
> working on is to change how that file is generated. Including it in the
> release tar-balls is something every project (that uses autoconf) does,
> since those are aimed at end-users.

Reason that it should be included:

* configure scripts usually are included.  git was the first source
code in a long time that I've seen without one
* we have lots other files in git.git that are autogenerated (the
documentation files, for example)
* people are used to being able to do "./configure; make; make install"
* It doesn't hurt anyone to do it.

John

Re: Chicken/egg problem building from a 'git clone'

[Jeff King]

On Thu, Mar 05, 2009 at 11:37:45AM +0000, John Tapsell wrote:

> > ./configure is a generated script. Including it in the repository is not
> > something many projects do, since one of the things developers will be
> > working on is to change how that file is generated. Including it in the
> > release tar-balls is something every project (that uses autoconf) does,
> > since those are aimed at end-users.
> 
> Reason that it should be included:
> 
> * configure scripts usually are included.  git was the first source
> code in a long time that I've seen without one

I think you are confusing "checked into version control" with
"distributed with release tarballs". Most projects do not do the
former[1], but almost all (including git) do the latter.

This discussion is about things checked into the repository.

[1] Sorry, I don't have exact numbers, but I have never encountered this
before.

> * we have lots other files in git.git that are autogenerated (the
> documentation files, for example)

I'm not aware of any auto-generated files that are checked in. Can you
give an example?

> * people are used to being able to do "./configure; make; make install"

Right. They do it from the release tarball. Getting the version straight
from source-control usually means you have to have autoconf if you want
to run it.

> * It doesn't hurt anyone to do it.

Yes, it does. Having generated files in your source repository means:

  - you generate useless noise commits when those files are
    re-autogenerated

  - developers must make sure that they are not accidentally committing
    auto-generated cruft that have nothing to do with their actual
    changes

-Peff

Re: Chicken/egg problem building from a 'git clone'

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

>> * we have lots other files in git.git that are autogenerated (the
>> documentation files, for example)
>
> I'm not aware of any auto-generated files that are checked in. Can you
> give an example?

man pages and html docs are commited, but in a separate branch. IOW,
Junio abuses Git as a distribution mechanism, but keeps it totally
separate from the actual sources.

> Yes, it does. Having generated files in your source repository means:
>
>   - you generate useless noise commits when those files are
>     re-autogenerated
>
>   - developers must make sure that they are not accidentally committing
>     auto-generated cruft that have nothing to do with their actual
>     changes

- You almost certainly get irrelevant conflicts when merging.

- Different developers using different autoconf versions that generate
  different code for the same source make even more noise that you'd
  expect ;-).

-- 
Matthieu

Re: Chicken/egg problem building from a 'git clone'

[Jeff King]

On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:

> >> * we have lots other files in git.git that are autogenerated (the
> >> documentation files, for example)
> >
> > I'm not aware of any auto-generated files that are checked in. Can you
> > give an example?
> 
> man pages and html docs are commited, but in a separate branch. IOW,
> Junio abuses Git as a distribution mechanism, but keeps it totally
> separate from the actual sources.

OK, true; but that is a totally different mechanism, unless the proposal
is to autobuild a "this would be the release tarball" branch similar to
html and man branches.

-Peff

Re: Chicken/egg problem building from a 'git clone'

[Jakub Narebski]

Jeff King <peff@peff.net> writes:
> On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
> 
>>>> * we have lots other files in git.git that are autogenerated (the
>>>> documentation files, for example)
>>>
>>> I'm not aware of any auto-generated files that are checked in. Can you
>>> give an example?
>> 
>> man pages and html docs are commited, but in a separate branch. IOW,
>> Junio abuses Git as a distribution mechanism, but keeps it totally
>> separate from the actual sources.
> 
> OK, true; but that is a totally different mechanism, unless the proposal
> is to autobuild a "this would be the release tarball" branch similar to
> html and man branches.

I thnk the proposal was to have 'configure' branch with configure
script built, similar to how 'html' and 'man' branches have built
documentation in HTML and manpages format.

However while toolchain needed to produce documentation (asciidoc +
xmlto) isn't, I think, something very common, in my opinion autoconf
is something that is present on systems containing other build tools
required to build git from sources.  So 'configure' branch is not, I
think, as necessary as 'html' and 'man' branches; additionally 'html'
branch (or the repository used to build documentation, or the
byproduct of building documentation) is used to generate on-line docs
for git.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Chicken/egg problem building from a 'git clone'

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> However while toolchain needed to produce documentation (asciidoc +
> xmlto) isn't, I think, something very common, in my opinion autoconf
> is something that is present on systems containing other build tools
> required to build git from sources.

Plus:

* an old ./configure script (taken from a previous tarball release)
  has good chance to work on a new Git. Since Makefile is designed to
  be useable without scripting, Junnio takes great care not to break
  existing setups.

* ./configure script is not mandatory to build Git from sources.

-- 
Matthieu

Re: Chicken/egg problem building from a 'git clone'

[Johannes Schindelin]

Hi,

On Fri, 6 Mar 2009, Jakub Narebski wrote:

> Jeff King <peff@peff.net> writes:
> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
> > 
> >>>> * we have lots other files in git.git that are autogenerated (the
> >>>> documentation files, for example)
> >>>
> >>> I'm not aware of any auto-generated files that are checked in. Can you
> >>> give an example?
> >> 
> >> man pages and html docs are commited, but in a separate branch. IOW,
> >> Junio abuses Git as a distribution mechanism, but keeps it totally
> >> separate from the actual sources.
> > 
> > OK, true; but that is a totally different mechanism, unless the proposal
> > is to autobuild a "this would be the release tarball" branch similar to
> > html and man branches.
> 
> I thnk the proposal was to have 'configure' branch with configure
> script built, similar to how 'html' and 'man' branches have built
> documentation in HTML and manpages format.
> 
> However while toolchain needed to produce documentation (asciidoc + 
> xmlto) isn't, I think, something very common, in my opinion autoconf is 
> something that is present on systems containing other build tools 
> required to build git from sources.  So 'configure' branch is not, I 
> think, as necessary as 'html' and 'man' branches; additionally 'html' 
> branch (or the repository used to build documentation, or the byproduct 
> of building documentation) is used to generate on-line docs for git.

Plus, keep in mind that autoconf support is only an afterthought in Git; 
Just running "make" is supposed to work.  If it does not, patches are 
certainly welcome, I think.

Ciao,
Dscho

Re: Chicken/egg problem building from a 'git clone'

[John Tapsell]

2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 6 Mar 2009, Jakub Narebski wrote:
>
>> Jeff King <peff@peff.net> writes:
>> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
>> >
>> >>>> * we have lots other files in git.git that are autogenerated (the
>> >>>> documentation files, for example)
>> >>>
>> >>> I'm not aware of any auto-generated files that are checked in. Can you
>> >>> give an example?
>> >>
>> >> man pages and html docs are commited, but in a separate branch. IOW,
>> >> Junio abuses Git as a distribution mechanism, but keeps it totally
>> >> separate from the actual sources.
>> >
>> > OK, true; but that is a totally different mechanism, unless the proposal
>> > is to autobuild a "this would be the release tarball" branch similar to
>> > html and man branches.
>>
>> I thnk the proposal was to have 'configure' branch with configure
>> script built, similar to how 'html' and 'man' branches have built
>> documentation in HTML and manpages format.
>>
>> However while toolchain needed to produce documentation (asciidoc +
>> xmlto) isn't, I think, something very common, in my opinion autoconf is
>> something that is present on systems containing other build tools
>> required to build git from sources.  So 'configure' branch is not, I
>> think, as necessary as 'html' and 'man' branches; additionally 'html'
>> branch (or the repository used to build documentation, or the byproduct
>> of building documentation) is used to generate on-line docs for git.
>
> Plus, keep in mind that autoconf support is only an afterthought in Git;
> Just running "make" is supposed to work.  If it does not, patches are
> certainly welcome, I think.

Well now that you mention it.. :-)

It doesn't check for the existance of asciidoc, but blindly assumes it
exists.  And even if you do have asciidoc, there's a good chance that
you have the wrong version.   The INSTALL file says that asciidoc
requires 8.2.7 but most distros (debian, ubuntu.  probably other) have
8.2.6.
If you compile the docs with the wrong asciidoc version, there is no
warning or error at all.  It just builds incorrect man pages.

John

asciidoc, was Re: Chicken/egg problem building from a 'git clone'

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2548 bytes --]

Hi,

On Fri, 6 Mar 2009, John Tapsell wrote:

> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 6 Mar 2009, Jakub Narebski wrote:
> >
> >> Jeff King <peff@peff.net> writes:
> >> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
> >> >
> >> >>>> * we have lots other files in git.git that are autogenerated (the
> >> >>>> documentation files, for example)
> >> >>>
> >> >>> I'm not aware of any auto-generated files that are checked in. Can you
> >> >>> give an example?
> >> >>
> >> >> man pages and html docs are commited, but in a separate branch. IOW,
> >> >> Junio abuses Git as a distribution mechanism, but keeps it totally
> >> >> separate from the actual sources.
> >> >
> >> > OK, true; but that is a totally different mechanism, unless the proposal
> >> > is to autobuild a "this would be the release tarball" branch similar to
> >> > html and man branches.
> >>
> >> I thnk the proposal was to have 'configure' branch with configure
> >> script built, similar to how 'html' and 'man' branches have built
> >> documentation in HTML and manpages format.
> >>
> >> However while toolchain needed to produce documentation (asciidoc +
> >> xmlto) isn't, I think, something very common, in my opinion autoconf is
> >> something that is present on systems containing other build tools
> >> required to build git from sources.  So 'configure' branch is not, I
> >> think, as necessary as 'html' and 'man' branches; additionally 'html'
> >> branch (or the repository used to build documentation, or the byproduct
> >> of building documentation) is used to generate on-line docs for git.
> >
> > Plus, keep in mind that autoconf support is only an afterthought in Git;
> > Just running "make" is supposed to work.  If it does not, patches are
> > certainly welcome, I think.
> 
> Well now that you mention it.. :-)
> 
> It doesn't check for the existance of asciidoc, but blindly assumes it
> exists.  And even if you do have asciidoc, there's a good chance that
> you have the wrong version.   The INSTALL file says that asciidoc
> requires 8.2.7 but most distros (debian, ubuntu.  probably other) have
> 8.2.6.
> If you compile the docs with the wrong asciidoc version, there is no
> warning or error at all.  It just builds incorrect man pages.

Frankly, I was talking about "make".  I never needed asciidoc there.

Besides, if it is really an itch of yours, maybe you can come up with a 
patch checking for a correct asciidoc version?  Only if asciidoc would be 
needed at all, of course.

Ciao,
Dscho

Re: asciidoc, was Re: Chicken/egg problem building from a 'git clone'

[John Tapsell]

2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 6 Mar 2009, John Tapsell wrote:
>
>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> > On Fri, 6 Mar 2009, Jakub Narebski wrote:
>> >
>> >> Jeff King <peff@peff.net> writes:
>> >> > On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
>> >> >
>> >> >>>> * we have lots other files in git.git that are autogenerated (the
>> >> >>>> documentation files, for example)
>> >> >>>
>> >> >>> I'm not aware of any auto-generated files that are checked in. Can you
>> >> >>> give an example?
>> >> >>
>> >> >> man pages and html docs are commited, but in a separate branch. IOW,
>> >> >> Junio abuses Git as a distribution mechanism, but keeps it totally
>> >> >> separate from the actual sources.
>> >> >
>> >> > OK, true; but that is a totally different mechanism, unless the proposal
>> >> > is to autobuild a "this would be the release tarball" branch similar to
>> >> > html and man branches.
>> >>
>> >> I thnk the proposal was to have 'configure' branch with configure
>> >> script built, similar to how 'html' and 'man' branches have built
>> >> documentation in HTML and manpages format.
>> >>
>> >> However while toolchain needed to produce documentation (asciidoc +
>> >> xmlto) isn't, I think, something very common, in my opinion autoconf is
>> >> something that is present on systems containing other build tools
>> >> required to build git from sources.  So 'configure' branch is not, I
>> >> think, as necessary as 'html' and 'man' branches; additionally 'html'
>> >> branch (or the repository used to build documentation, or the byproduct
>> >> of building documentation) is used to generate on-line docs for git.
>> >
>> > Plus, keep in mind that autoconf support is only an afterthought in Git;
>> > Just running "make" is supposed to work.  If it does not, patches are
>> > certainly welcome, I think.
>>
>> Well now that you mention it.. :-)
>>
>> It doesn't check for the existance of asciidoc, but blindly assumes it
>> exists.  And even if you do have asciidoc, there's a good chance that
>> you have the wrong version.   The INSTALL file says that asciidoc
>> requires 8.2.7 but most distros (debian, ubuntu.  probably other) have
>> 8.2.6.
>> If you compile the docs with the wrong asciidoc version, there is no
>> warning or error at all.  It just builds incorrect man pages.
>
> Frankly, I was talking about "make".  I never needed asciidoc there.
>
> Besides, if it is really an itch of yours, maybe you can come up with a
> patch checking for a correct asciidoc version?  Only if asciidoc would be
> needed at all, of course.

Yep.  I've been looking at it for the last half hour, but configure.ac
syntax defeats me :-D   (I figured getting the check into configure.ac
 would be a good first start)

Re: asciidoc, was Re: Chicken/egg problem building from a 'git clone'

[Jakub Narebski]

On Fri, 6 March 2009, John Tapsell wrote:
> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> On Fri, 6 Mar 2009, John Tapsell wrote:
>>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>>> On Fri, 6 Mar 2009, Jakub Narebski wrote:

>>>>> However while toolchain needed to produce documentation (asciidoc +
>>>>> xmlto) isn't, I think, something very common, in my opinion autoconf is
>>>>> something that is present on systems containing other build tools
>>>>> required to build git from sources.  So 'configure' branch is not, I
>>>>> think, as necessary as 'html' and 'man' branches; additionally 'html'
>>>>> branch (or the repository used to build documentation, or the byproduct
>>>>> of building documentation) is used to generate on-line docs for git.
>>>>
>>>> Plus, keep in mind that autoconf support is only an afterthought in Git;
>>>> Just running "make" is supposed to work.  If it does not, patches are
>>>> certainly welcome, I think.
>>>
>>> Well now that you mention it.. :-)
>>>
>>> It doesn't check for the existance of asciidoc, but blindly assumes it
>>> exists.  And even if you do have asciidoc, there's a good chance that
>>> you have the wrong version.   The INSTALL file says that asciidoc
>>> requires 8.2.7 but most distros (debian, ubuntu.  probably other) have
>>> 8.2.6.

Do you mean here Makefile checks, or do you mean ./configure checking
for existing asciidoc toolchain, and for asciidoc version?

>>> If you compile the docs with the wrong asciidoc version, there is no
>>> warning or error at all.  It just builds incorrect man pages.
>>
>> Frankly, I was talking about "make".  I never needed asciidoc there.
>>
>> Besides, if it is really an itch of yours, maybe you can come up with a
>> patch checking for a correct asciidoc version?  Only if asciidoc would be
>> needed at all, of course.
> 
> Yep.  I've been looking at it for the last half hour, but configure.ac
> syntax defeats me :-D   (I figured getting the check into configure.ac
> would be a good first start)

Errr... doesn't configure.ac have checking for asciidoc version? Search
for AC_CHECK_PROGS(ASCIIDOC, [asciidoc]). Perhaps tests should be more
detailed, or something...

-- 
Jakub Narebski
Poland

Re: asciidoc, was Re: Chicken/egg problem building from a 'git clone'

[John Tapsell]

2009/3/6 Jakub Narebski <jnareb@gmail.com>:
> On Fri, 6 March 2009, John Tapsell wrote:
>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>> On Fri, 6 Mar 2009, John Tapsell wrote:
>>>> 2009/3/6 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>>>> On Fri, 6 Mar 2009, Jakub Narebski wrote:
>
>>>>>> However while toolchain needed to produce documentation (asciidoc +
>>>>>> xmlto) isn't, I think, something very common, in my opinion autoconf is
>>>>>> something that is present on systems containing other build tools
>>>>>> required to build git from sources.  So 'configure' branch is not, I
>>>>>> think, as necessary as 'html' and 'man' branches; additionally 'html'
>>>>>> branch (or the repository used to build documentation, or the byproduct
>>>>>> of building documentation) is used to generate on-line docs for git.
>>>>>
>>>>> Plus, keep in mind that autoconf support is only an afterthought in Git;
>>>>> Just running "make" is supposed to work.  If it does not, patches are
>>>>> certainly welcome, I think.
>>>>
>>>> Well now that you mention it.. :-)
>>>>
>>>> It doesn't check for the existance of asciidoc, but blindly assumes it
>>>> exists.  And even if you do have asciidoc, there's a good chance that
>>>> you have the wrong version.   The INSTALL file says that asciidoc
>>>> requires 8.2.7 but most distros (debian, ubuntu.  probably other) have
>>>> 8.2.6.
>
> Do you mean here Makefile checks, or do you mean ./configure checking
> for existing asciidoc toolchain, and for asciidoc version?

Well presumably both would have to check, since you can run make
without configure.  I just figured starting with configure would be
easiest.

>
>>>> If you compile the docs with the wrong asciidoc version, there is no
>>>> warning or error at all.  It just builds incorrect man pages.
>>>
>>> Frankly, I was talking about "make".  I never needed asciidoc there.
>>>
>>> Besides, if it is really an itch of yours, maybe you can come up with a
>>> patch checking for a correct asciidoc version?  Only if asciidoc would be
>>> needed at all, of course.
>>
>> Yep.  I've been looking at it for the last half hour, but configure.ac
>> syntax defeats me :-D   (I figured getting the check into configure.ac
>> would be a good first start)
>
> Errr... doesn't configure.ac have checking for asciidoc version? Search
> for AC_CHECK_PROGS(ASCIIDOC, [asciidoc]). Perhaps tests should be more
> detailed, or something...

Yeah I saw that - it checks if you have version 7.* or 8.*. I just
don't know how to check if the version is >= .8.2.7.

John