Autoconf/Automake

Autoconf/Automake

[Pavel Roskin]

Hello!

Is there any interest in converting the build system used by git to
Autoconf and Automake?  The ad-hoc configuration in Makefile is getting
too big.  As for nice features like remembering $prefix, wouldn't it be
better to add them to Automake instead of limiting them to just one
project?

Other goodies from Automake are "make distcheck" and automatic
dependency tracking.  Compatibility with non-GNU make could earn us some
respect from BSD folks.

I converted several projects to the GNU build system, including qgit.
It may be hard to get right, but then it just works for any
configuration without giving any trouble.

-- 
Regards,
Pavel Roskin

Re: Autoconf/Automake

[Linus Torvalds]

On Wed, 14 Jun 2006, Pavel Roskin wrote:
> 
> Is there any interest in converting the build system used by git to
> Autoconf and Automake?  The ad-hoc configuration in Makefile is getting
> too big.

NO! At least the Makefile is debuggable and understandable.

If we need a better build system, I'd much rather use something 
higher-level that can generate VC++ project files etc. 

In other words, I'd much rather see us using CMake or something like that, 
which actually adds real value-add.

(And no, I've never used cmake, so maybe it has horrors waiting for us 
too, but autoconf is just worthless).

			Linus

Re: Autoconf/Automake

[Bertrand Jacquin]

On 6/15/06, Pavel Roskin <proski@gnu.org> wrote:
> Hello!
>
> Is there any interest in converting the build system used by git to
> Autoconf and Automake?  The ad-hoc configuration in Makefile is getting
> too big.  As for nice features like remembering $prefix, wouldn't it be
> better to add them to Automake instead of limiting them to just one
> project?

Autofoo are pretty good but it's unix make dependant, can't create
build files for other build system as Visual, or so on. How don't lost
his hairs trying to do autofood his project ?
CMake seems to be as good for git. And is also expansible.
Git Makefile is quiet big but not complex, autofood imho will make it
less stable and usable.

-- 
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}

Re: Autoconf/Automake

[Timo Hirvonen]

Pavel Roskin <proski@gnu.org> wrote:

> Hello!
> 
> Is there any interest in converting the build system used by git to
> Autoconf and Automake?  The ad-hoc configuration in Makefile is getting
> too big.  As for nice features like remembering $prefix, wouldn't it be
> better to add them to Automake instead of limiting them to just one
> project?
> 
> Other goodies from Automake are "make distcheck" and automatic
> dependency tracking.  Compatibility with non-GNU make could earn us some
> respect from BSD folks.
> 
> I converted several projects to the GNU build system, including qgit.
> It may be hard to get right, but then it just works for any
> configuration without giving any trouble.

Autotools almost drove me crazy so I had to write my own configure
system:

   http://onion.dynserv.net/~timo/tconf.html

It is really easy to use and quite flexible.</shameless plug>

Personally I don't think git needs autoconf/tconf/whatever. The current
makefile is good enough.

-- 
http://onion.dynserv.net/~timo/

Re: Autoconf/Automake

[Yann Dirson]

On Wed, Jun 14, 2006 at 06:27:10PM -0400, Pavel Roskin wrote:
> Is there any interest in converting the build system used by git to
> Autoconf and Automake?  The ad-hoc configuration in Makefile is getting
> too big.  As for nice features like remembering $prefix, wouldn't it be
> better to add them to Automake instead of limiting them to just one
> project?

Since there are many people objecting to autotools, what about using
Jam instead ?  It has the advantage of being designed to be
cross-platform, and should have all the features we would need for *git.

When compared to autotools, it rather takes the place of automake, and
can also be use together with autoconf (or any non-make-specific
replacement you can name) if there is a need for it.

Best regards,
-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: Autoconf/Automake

[Alex Riesen]

Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:
> > Is there any interest in converting the build system used by git to
> > Autoconf and Automake?  The ad-hoc configuration in Makefile is getting
> > too big.  As for nice features like remembering $prefix, wouldn't it be
> > better to add them to Automake instead of limiting them to just one
> > project?
> 
> Since there are many people objecting to autotools, what about using
> Jam instead ?  It has the advantage of being designed to be
> cross-platform, and should have all the features we would need for *git.

Except that it is not readily available everywhere, has unreadable
and illogical syntax, and lots of unknown assumptions built in.
We are forced to use that thing at work, and it is mostly hated.

Git already has enough external dependencies (crypto, Python, Perl,
bash, gmake), why create another one?

If we are about to need a configuration system (and I doubt it), may
be we should at least select a system small enough to have it always
in git repo? (yes, as linux kernel configuration system is)

Re: Autoconf/Automake

[Yann Dirson]

On Thu, Jun 15, 2006 at 03:31:46PM +0200, Alex Riesen wrote:
> Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:
> > Since there are many people objecting to autotools, what about using
> > Jam instead ?  It has the advantage of being designed to be
> > cross-platform, and should have all the features we would need for *git.
> 
> Except that it is not readily available everywhere, has unreadable
> and illogical syntax, and lots of unknown assumptions built in.
> We are forced to use that thing at work, and it is mostly hated.

Well, being hated is often the fate of tools for which users got no
training, but are forced to used because of a corporate decision.
That does not necessarily mean the tool is bad in itself.

> If we are about to need a configuration system (and I doubt it), may
> be we should at least select a system small enough to have it always
> in git repo? (yes, as linux kernel configuration system is)

The kernel is a beast that is specific enough to need its own build
system, and does not support that many platforms, IIRC.  Wrong
example, if you want my opinion :)

Best regards,
-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: Autoconf/Automake

[Linus Torvalds]

On Thu, 15 Jun 2006, Yann Dirson wrote:
> 
> Well, being hated is often the fate of tools for which users got no
> training, but are forced to used because of a corporate decision.

That's one possible reason.

> That does not necessarily mean the tool is bad in itself.

It does not _necessarily_ mean that, but let's face it, it really usually 
does.

Too many developers shrug off the "it's hard to use" argument. THEY think 
it's fine. THEY think it's "lack of training". THEY think the tools are 
fine, and the problem is the user.

THEY are wrong.

Almost every time when a user says "it's hard to use", the user is right. 
Sometimes it's a lack of documentation, but quite often it's just that the 
tool interfaces are bad.

Oh, I'm sure git has the same problems, but dammit, I think we've tried 
very hard to listen to user opinions, and make the things that make them 
go "that's hard" be more obvious. All the things that were _possible_ to 
do if you did them by hand, that you now can do pretty obviously without 
even knowing what it really does. "git commit -a". "git log -p". "git show 
<name>", etc etc. 

Sometimes the problem space makes the interfaces fundamentally hard. But 
sometimes the program itself just makes things ugly and hard, and autoconf 
and automake definitely didn't make it easier for users - they were 
designed for people who knew fifteen different versions of UNIX, and not 
for sane people.

These days, there aren't fifteen different versions of UNIX. There's a 
couple, and it's perfectly ok to actually say "fix your damn system and 
just install GNU make". It's easier to install GNU make than it is to 
install autoconf/automake.

		Linus

Re: Autoconf/Automake

[Olivier Galibert]

On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
> These days, there aren't fifteen different versions of UNIX. There's a 
> couple, and it's perfectly ok to actually say "fix your damn system and 
> just install GNU make". It's easier to install GNU make than it is to 
> install autoconf/automake.

You should be careful to separate autoconf and automake.  Autoconf is
not so bad, and you can make clean, maintainable Makefile.in and
config.h.in files with it, because it uses simple substitution.  It is
quite useful to detect available librairies when some are optional,
and also to lightly[1] ensure that prefix and friends will stay the
same between make and make install.  Also, especially if you hack a
little bit to alias 'enable' and 'with', you get a sane interface to
optional feature selection.  Oh, and to seperate compilation
directories too (vpath generation).

OTOH, automake is a BDSM session gone bad.  The makefiles it generates
are atrocious and outdated, even buggy on some lesser makes, which is
quite annoying when what you try to build is gnu make.

The worst of the lot is libtool, though.  That one explicitely tries
to make your experience as painful as possible.  Including, but not
limited to, hiding the files in dot-directories so that you try to run
gdb on a script, relinking at install time, silently removing flags
you want to pass to ld or the compiler because it thinks it knows
better, locking C++ shared libraries to the exact compiler version
that compiled them through the .la file crap, etc.

So, autoconf can be useful.  The rest should die.

  OG.

[1] As in, you can still override when running make, but if you don't
    override anything you'll get the value you passed to configure every
    time.

Re: Autoconf/Automake

[Jakub Narebski]

Olivier Galibert wrote:

> On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
>> These days, there aren't fifteen different versions of UNIX. There's a 
>> couple, and it's perfectly ok to actually say "fix your damn system and 
>> just install GNU make". It's easier to install GNU make than it is to 
>> install autoconf/automake.
> 
> You should be careful to separate autoconf and automake.  Autoconf is
> not so bad, and you can make clean, maintainable Makefile.in and
> config.h.in files with it, because it uses simple substitution.
[...]
> So, autoconf can be useful.  The rest should die.

Does autoconf generate configure script in POSIX shell, or in bash?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Autoconf/Automake

[Olivier Galibert]

On Thu, Jun 15, 2006 at 08:03:56PM +0200, Jakub Narebski wrote:
> Does autoconf generate configure script in POSIX shell, or in bash?

It seems that it still generates bare /bin/sh compatible scripts.
ICBvery easilyW, though.

  OG.

Re: Autoconf/Automake

[Petr Baudis]

Dear diary, on Thu, Jun 15, 2006 at 08:03:56PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Does autoconf generate configure script in POSIX shell, or in bash?

/bin/sh, but on such a degree that it avoids using even functions -
which makes the resulting ./configure script quite awful. autoconf is
*much* better than automake (libtool I shall refrain commenting on
entirely; eeeek) in that you have much more free hand in bending it
in case it does something stupid, but the resulting ./configure script
is still mammoth and barely readable.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: Autoconf/Automake

[Jerome Lovy]

Olivier Galibert wrote:
> On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
> 
>>These days, there aren't fifteen different versions of UNIX. There's a 
>>couple, and it's perfectly ok to actually say "fix your damn system and 
>>just install GNU make". It's easier to install GNU make than it is to 
>>install autoconf/automake.
> 
> 
> You should be careful to separate autoconf and automake.  Autoconf is
> not so bad, and you can make clean, maintainable Makefile.in and
> config.h.in files with it, because it uses simple substitution.  It is
> quite useful to detect available librairies when some are optional,
> and also to lightly[1] ensure that prefix and friends will stay the
> same between make and make install.  Also, especially if you hack a
> little bit to alias 'enable' and 'with', you get a sane interface to
> optional feature selection.  Oh, and to seperate compilation
> directories too (vpath generation).

I fully agree with Olivier. It seems to me that you don't have to buy 
the whole autoconf/automake/libtool stack to leverage the autoconf 
functionality. autoconf alone provides the full "autoconfiguration" 
framework (running scriptlets and setting substitution variables 
accordingly). You still have to write Makefile.in (with statements 
looking like: CC=@CC@). Therefore the resulting Makefile is just as 
beautiful or as ugly as you wrote the initial Makefile.in: you have full 
control over it.

As for dependencies, one shouldn't confuse what is needed on the 
autoconfiguration developer's side (in order to build the configure 
script from the configure.in file) and what is needed on the installer's 
side to run the configure script and process the generated makefile. The 
former needs the autoconf package which itself relies on GNU m4. The 
latter merely needs a decently compatible Bourne shell and a decently 
compatible make.

On the other hand, what you get with automake is a fully automatically 
generated makefile, with make targets conforming to the GNU standards. 
But then you fully loose control over the Makefile: you don't write the 
Makefile.in anymore (automake does it for you) but rather the terce 
Makefile.am. In this respect, automake is like imake: you write few 
lines of (i)makefile, but then you cannot complain if you don't 
understand what comes in the generated makefile ;-) .

Jérôme Lovy

Re: Autoconf/Automake

[Yakov Lerner]

On 6/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
> These days, there aren't fifteen different versions of UNIX. There's a
> couple, and it's perfectly ok to actually say "fix your damn system and
> just install GNU make". It's easier to install GNU make than it is to
> install autoconf/automake.

It's easier to learn GNUmake than to learn autoconf/automake or jam, too.

However, the idea of compiling small pieces of main() at the
configure-time to automatically figure what exactly is available --
I like how well this approach works. It works more
precisely than relying on uname.

Yakov

Re: Autoconf/Automake

[Yann Dirson]

On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
> Too many developers shrug off the "it's hard to use" argument. THEY think 
> it's fine. THEY think it's "lack of training". THEY think the tools are 
> fine, and the problem is the user.
> 
> THEY are wrong.
> 
> Almost every time when a user says "it's hard to use", the user is right. 
> Sometimes it's a lack of documentation, but quite often it's just that the 
> tool interfaces are bad.

In tha case of jam, the doc issue can certainly be raised, but the
most prominent problem is probably that everyone and their dog knows
make, and expects a replacement to work in a similar fashion.  The
current documentation and tutorial unfortunately does not show
precisely how people used to "make" can easily switch to jam.

For those not knowing about jam, I'd say the 1st thing to anchor in
one's mind is that jam gives complete (programmatic) control on the
dependency tree (eg. you just have to write once that the results of a
compilation have to be removed by "jam clean", and everytime you
declare a file to be built with your rule, you don't have to remember
to add it to the Clean rule - and more importantly, as soon as you
remove that declaration, you don't have to fear the Clean target to
remove it, in case it would be precious).


> Sometimes the problem space makes the interfaces fundamentally hard. But 
> sometimes the program itself just makes things ugly and hard, and autoconf 
> and automake definitely didn't make it easier for users - they were 
> designed for people who knew fifteen different versions of UNIX, and not 
> for sane people.
> 
> These days, there aren't fifteen different versions of UNIX. There's a 
> couple, and it's perfectly ok to actually say "fix your damn system and 
> just install GNU make". It's easier to install GNU make than it is to 
> install autoconf/automake.

Right, autoconf would be much more sane if it would not insist on
supporting vintage unices. OTOH, people having to work on these
systems (eg. for professional reason - not everyone has the luck to
work with modern systems all the time) are more than happy to be able
to build some recent tools to make there task easier.  Except when it
fails in that task (eg. a configure script for the bash package
failing to run on an years-old lynxos version because of a sh bug on
the OS), it still does a wonderful job in the end.

But I agree having to carry all this compat stuff, when one just wants
to benefit from higher-level features (like those mentionned by
Oliver), is annoying.  Maybe the support for legacy platforms could be
restricted in some way to the bare minimum.  Eg. using a "legacy"
backend where the cruft would go, and stubs for modern things, that
would generate a hopefully-more-portable-but-limited
./configure-simple script, and a "modern" backend generating a sane
full-fledged bash script.

But I'm going off-topic :)

Best regards,
-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: Autoconf/Automake

[Linus Torvalds]

On Thu, 15 Jun 2006, Yann Dirson wrote:
> 
> In tha case of jam, the doc issue can certainly be raised, but the
> most prominent problem is probably that everyone and their dog knows
> make,

Oh, I agree. A "simpler" thing that people don't know is often much 
inferior to a complex thing that people are generally intimately familiar 
with.

I just personally believe that autoconf/automake are the worst of both 
worlds (ie it's a _complex_ thing that a lot of people don't know).

GNU make in many ways is actually not that bad. Yeah, the makefiles get 
more complex, but it's usually not totally unreadable, and you can do some 
clever stuff with it. 

The kernel makefiles are a pretty extreme example (and it hides a lot of 
the complexity in files that get included and that most people never ever 
need to look at). I suspect that git could more easily do something like 
that (on a _much_ smaller scale - don't get me wrong).

			Linus

Re: Autoconf/Automake

[Johannes Schindelin]

Hi,

On Thu, 15 Jun 2006, Linus Torvalds wrote:

> On Thu, 15 Jun 2006, Yann Dirson wrote:
> > 
> > In tha case of jam, the doc issue can certainly be raised, but the
> > most prominent problem is probably that everyone and their dog knows
> > make,
> 
> Oh, I agree. A "simpler" thing that people don't know is often much 
> inferior to a complex thing that people are generally intimately familiar 
> with.
> 
> I just personally believe that autoconf/automake are the worst of both 
> worlds (ie it's a _complex_ thing that a lot of people don't know).
> 
> GNU make in many ways is actually not that bad. Yeah, the makefiles get 
> more complex, but it's usually not totally unreadable, and you can do some 
> clever stuff with it. 

I can add to that with first-hand experience of ant and maven.

A whole sh*t-load of people think make is broken. It does not live up to 
what they want, and it is slow.

And then they invent a _DISEASE_ like ant, which _does not begin_ to sport 
the features of make.

In a project I am stuck in, maven is used. It tries -- of all things -- to 
fix a few shortcomings of ant -- which was supposed to fix shortcomings of 
make! And let's face it. Maven is complicated, slow as a dog lacking all 
four feet, and it still does not do the things I can do in three lines 
with make. It's a complete desaster.

So to keep the discussion on topic: tell me what you want to fix wrt the 
current setup of git, and I'll try to fix it in less than 10 lines of make 
code. If that is impossible, let's continue then and there with the 
discussion about a switch to a newer, less tested, replacement of make, 
okay?

Ciao,
Dscho

Re: Autoconf/Automake

[Nikolai Weibull]

On 6/16/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> In a project I am stuck in, maven is used. It tries -- of all things -- to
> fix a few shortcomings of ant -- which was supposed to fix shortcomings of
> make! And let's face it. Maven is complicated, slow as a dog lacking all
> four feet, and it still does not do the things I can do in three lines
> with make. It's a complete desaster.

But...it uses XML...how can it not be a panacea?

  nikolai

Re: Autoconf/Automake

[Phil Richards]

On 2006-06-15, Alex Riesen <fork0@t-online.de> wrote:
>  Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:
> > Since there are many people objecting to autotools, what about using
> > Jam instead ?  It has the advantage of being designed to be
> > cross-platform, and should have all the features we would need for *git.
>  Except that it is not readily available everywhere, has unreadable
>  and illogical syntax, and lots of unknown assumptions built in.
>  We are forced to use that thing at work, and it is mostly hated.

FWIW, I like Boost and use it every day.  I hate bjam.

>  Git already has enough external dependencies (crypto, Python, Perl,
>  bash, gmake), why create another one?
> 
>  If we are about to need a configuration system (and I doubt it), may
>  be we should at least select a system small enough to have it always
>  in git repo? (yes, as linux kernel configuration system is)

Well, since Python is already a dependency, why not use a build system
that has Python as its scripting/extension language?  It's also quite
small, and it's called SCons.  I found it rather easy to learn
when I was having a quick look around at alternative build systems.

Just a thought.

phil
-- 
change name before "@" to "phil" for email

Re: Autoconf/Automake

[Timo Hirvonen]

Phil Richards <news@derived-software.ltd.uk> wrote:

> Well, since Python is already a dependency, why not use a build system
> that has Python as its scripting/extension language?  It's also quite
> small, and it's called SCons.  I found it rather easy to learn
> when I was having a quick look around at alternative build systems.

Only git-merge-recursive depends on Python. I hope it will be rewritten
in C some day.

-- 
http://onion.dynserv.net/~timo/

Re: Autoconf/Automake

[Johannes Schindelin]

Hi,

On Thu, 15 Jun 2006, Phil Richards wrote:

> On 2006-06-15, Alex Riesen <fork0@t-online.de> wrote:
>
> >  Git already has enough external dependencies (crypto, Python, Perl,
> >  bash, gmake), why create another one?
> > 
> >  If we are about to need a configuration system (and I doubt it), may
> >  be we should at least select a system small enough to have it always
> >  in git repo? (yes, as linux kernel configuration system is)
> 
> Well, since Python is already a dependency, why not use a build system
> that has Python as its scripting/extension language?  It's also quite
> small, and it's called SCons.  I found it rather easy to learn
> when I was having a quick look around at alternative build systems.

Okay, let's face it. There are gazillions of make clones which "guarantee" 
to fix all shortcomings of make. None of them are even close to make 
(regarding developer exposure: take 3 developers, and 1 does not know 
make, and 2 do not know whatever-your-favourite-make-clone-is).

As for now, I fail to see why the current system is not adequate for git!

Ciao,
Dscho

Re: Autoconf/Automake

[Yann Dirson]

On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> As for now, I fail to see why the current system is not adequate for git!

I can reassure you, gazillions of people still fail to see why cvs is
not adequate for their project.  And the ratio of devs in the
corporate world not knowning git to those not knowning cvs is far
superior to 2.  And everyone here knows cvs is not more adequate than
git for so many tasks :)

Best regards,
-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: Autoconf/Automake

[Johannes Schindelin]

Hi,

On Fri, 16 Jun 2006, Yann Dirson wrote:

> On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > As for now, I fail to see why the current system is not adequate for git!
> 
> I can reassure you, gazillions of people still fail to see why cvs is
> not adequate for their project.  And the ratio of devs in the
> corporate world not knowning git to those not knowning cvs is far
> superior to 2.  And everyone here knows cvs is not more adequate than
> git for so many tasks :)

You know as well as I that this comparison is unfair. I am _NOT_ a 
corporate person. I hope that you do not judge me as a complete airhead.

The point is: the right tool solves the problem. You can have a tool which 
is mighty cool, but way too powerful (AKA complicated).

As for CVS: there _are_ a few use cases where CVS is just the right tool. 
There are many more use cases where git is more than adequate, where CVS 
is not.

_BUT_: there are cases where something like autoconf/jam/cmake/blablabla 
is adequate, but I still fail to see why for git, the makefile system 
should not work. It is the most transparent way to configure a make system 
I encountered. It is short, concise, and does the job. And I understand 
it. As opposed to autoconf/jam/cmake/blablabla.

Hth,
Dscho

Re: Autoconf/Automake

[Yann Dirson]

On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:
> > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > > As for now, I fail to see why the current system is not adequate for git!
> > 
> > I can reassure you, gazillions of people still fail to see why cvs is
> > not adequate for their project.  And the ratio of devs in the
> > corporate world not knowning git to those not knowning cvs is far
> > superior to 2.  And everyone here knows cvs is not more adequate than
> > git for so many tasks :)
> 
> You know as well as I that this comparison is unfair. I am _NOT_ a 
> corporate person. I hope that you do not judge me as a complete airhead.

Well, I have to apologize - especially after looking closer at the
current Makefile.  I think I understand now why autoconf was suggested
in the first place, but it what it would achieve would mostly moving
the ifdef's to configure.ac, which would not be such a gain anyway.

Best regards,
-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

Re: Autoconf/Automake

[Petr Baudis]

Dear diary, on Fri, Jun 16, 2006 at 10:17:15PM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> On Fri, Jun 16, 2006 at 12:58:30AM +0200, Johannes Schindelin wrote:
> > > On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > > > As for now, I fail to see why the current system is not adequate for git!
> > > 
> > > I can reassure you, gazillions of people still fail to see why cvs is
> > > not adequate for their project.  And the ratio of devs in the
> > > corporate world not knowning git to those not knowning cvs is far
> > > superior to 2.  And everyone here knows cvs is not more adequate than
> > > git for so many tasks :)
> > 
> > You know as well as I that this comparison is unfair. I am _NOT_ a 
> > corporate person. I hope that you do not judge me as a complete airhead.
> 
> Well, I have to apologize - especially after looking closer at the
> current Makefile.  I think I understand now why autoconf was suggested
> in the first place, but it what it would achieve would mostly moving
> the ifdef's to configure.ac, which would not be such a gain anyway.

Except that then I don't need to bother manually adding NO_EXPAT to the
makefile on all systems I compile git on.

Yes, it's not a huge bother per se, but since almost all other
non-obscure projects do figure these things out automagically, git kind
of stands out negatively here. "Wah, it needs me tweak the Makefile to
be able to compile it."

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: Autoconf/Automake

[Petr Baudis]

Dear diary, on Fri, Jun 16, 2006 at 12:05:34AM CEST, I got a letter
where Yann Dirson <ydirson@altern.org> said that...
> On Thu, Jun 15, 2006 at 10:42:40PM +0200, Johannes Schindelin wrote:
> > As for now, I fail to see why the current system is not adequate for git!
> 
> I can reassure you, gazillions of people still fail to see why cvs is
> not adequate for their project.  And the ratio of devs in the
> corporate world not knowning git to those not knowning cvs is far
> superior to 2.  And everyone here knows cvs is not more adequate than
> git for so many tasks :)

Duh. That works the same way when I replace the original question with
"As for now, I fail to see to see why Linux is not adequate for my
desktop! (In contrast with AIX.)".

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.