--nextPart6531461.qW1KSeRChZ
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 13 June 2005 22:23, David Johnson wrote:
> On Monday 13 June 2005 05:01 am, Guillaume Laurent wrote:
> > Or more likely, that it's based on 'make' and sh, which every unix
> > platform has installed by debault.
>
> This is a big advantage which shouldn't be discounted too quickly. Make
> and bourne shell are two nearly universal programming tools, and one
> could reasonable expect most (unix) developers to be familiar with
> them.

Huh?  We don't in general directly interact with make and sh anyways. =20
Makefile.am's are for the most part foo_SOMETHING =3D blah $(foo2) which is=
n't=20
anywhere near a Makefile syntax.  Sure you can add make-specific stuff if y=
ou=20
want, but for the most part it's not exposed to us.

Likewise with sh.  I think there are much more people familiar (or could=20
quickly become familiar) with Python, Ruby, et al. than could use m4.  If w=
e=20
use sh for familiarity then we get into the issue of various shell-specific=
s,=20
like features which work with shell foo but not shell bar.  I think if you'=
re=20
experienced enough to deal with sh portability issues then you can handle=20
some Python. :P

Besides, there's no reason that people have to be forced into using the=20
language syntax, there's no reason that if the build system were written in=
=20
Python or Ruby or what have you that it couldn't still read Makefile.am and=
=20
some form of simple configure script.

But either way, make and sh experience is bogus, no one actually uses those=
=20
levels.  It's all m4 macros and automake-hocus-pocus.

> On the other hand, much fewer developers are familar with Python=20
> or other  high level scripting languages.

You need to back this up, I call bullshit.  Typing "updatedb" into a shell=
=20
script to be called from cron does not an sh expert make.  Besides that I c=
an=20
almost guarantee that use of shell in configure scripts in KDE is almost=20
always copied from somewhere else until it works.  Few people actually have=
 a=20
clue what they're doing. :P

> I don't want to detract from any solutions using Python or other
> language, but we must make sure we don't create too steep of a learning
> curve for developers who don't want to sit down and learn a new
> language just to get their C++ application installed.

They can program C++, but they can't handle (Python|Ruby|foo) with=20
instructions and dozens of other configure scripts to copy?

I guarantee people wouldn't be fleeing autotools left and right if it were=
=20
easy to use.

Regards,
 - Michael Pyne

--nextPart6531461.qW1KSeRChZ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCrkgSqjQYp5Omm0oRAjJfAKDbVwdR1iD+0MjxEPCKo53T3eqUBQCfeB8e
61sy2LsrIkNARex7e4CKU2w=
=QRcC
-----END PGP SIGNATURE-----

--nextPart6531461.qW1KSeRChZ--