You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Patrick Welche <pr...@newn.cam.ac.uk> on 2004/02/15 15:37:30 UTC
apr/apr-util python dependence
I see that good work has been done to clean up the twisty building maze
in apr and apr-util. I suppose I want my cake and eat it - would you object
to a translation of the two python scripts into ordinary sh, avoiding the
need for those of us who haven't installed python to do so just for those
two files? If anything I would prefer a dependence on automake rather than
python.. that might make things even easier..
Cheers,
Patrick
Re: apr/apr-util python dependence
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz wrote:
> --On Sunday, February 15, 2004 1:06 PM -0500 Jeff Trawick
> <tr...@attglobal.net> wrote:
>
>> I'd guess that a conversion to the less cool but more widely
>> ported/precompiled/preinstalled P* scripting language would be a rather
>> quick and would not suffer greatly from uncoolness and would pick up
>> additional people able and/or willing to maintain it ;)
>
>
> If you did that, I bet we'd lose people willing to maintain it. ;-)
No surprise there ;) But I would guess that part of the elevation in
importance of willing-ness vs. able-ness + availability in choice of
implementation languages is due to most people not having choices like these to
consider:
a) go find some way to build Python on z/OS; I've found some site that claims
to have patches to make it work; haven't tried yet though; also, there are
multiple levels of the OS that I use with widely varying capabilities; possibly
more invention may be required to support V2R8
b) create a mechanism where I can easily transfer the output of the python to
z/OS and also fix the charset issue with gen-test-chars
c) rewrite what seems like a relatively small amount of Python into Perl or
sh+sed+whatever
Choice c) is the only permanent solution that is done once and then everybody
benefits from. For now there aren't enough hours in the day to mess with it.
Re: apr/apr-util python dependence
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, February 15, 2004 1:06 PM -0500 Jeff Trawick
<tr...@attglobal.net> wrote:
> I'd guess that a conversion to the less cool but more widely
> ported/precompiled/preinstalled P* scripting language would be a rather
> quick and would not suffer greatly from uncoolness and would pick up
> additional people able and/or willing to maintain it ;)
If you did that, I bet we'd lose people willing to maintain it. ;-)
And, yes, automake is a dirty word. I want it very, very far away from any
projects I work on... -- justin
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
> As part of the configure process, I would agree with you, but as part of
> buildconf, I disagree--not everyone needs to run buildconf--only
> developers, and if you're a developer, it's *really* not asking that
> much to have Python on your dev box.
That must be a wonderful world where you run buildconf only
on boxes which are under your control all the time.
In reality, build system debugging is often required on
awkward systems where even a pervasive language such as perl
is often unavailable.
> Ick. Ick ick ick ick ick. "Easily" is obviously a subjective term. Who
> wants to write (and, more importantly, *maintain*) hundreds (or
> thousands) of lines of /bin/sh code?
Many people do that all the time.
> Not to mention the fact that Python can be much more compact
> than /bin/sh after you hit a certain level of complexity.
Build systems don't reach that level.
> Anyway, I suppose that agreeing to disagree may be for the best here.
Agreed. I'll rewrite the .py script on my way tonight and
submit it for review.
- Sascha
Re: apr/apr-util python dependence
Posted by Bill Stoddard <bi...@wstoddard.com>.
Roy T. Fielding wrote:
>>> However I completely disagree that Python (or Perl or PHP) is
>>> a good choice for use in build systems.
>>
>>
>> As part of the configure process, I would agree with you, but as part of
>> buildconf, I disagree--not everyone needs to run buildconf--only
>> developers, and if you're a developer, it's *really* not asking that
>> much to have Python on your dev box.
>
>
> Sure it is. If I wasn't so busy I would have vetoed the change on
> the grounds that it causes httpd to no longer be buildable by developers
> on the Cray MP. And no, I don't care whether anyone else thinks that
> is an important requirement. Creating entry barriers is what prevents
> development on new platforms that you haven't even heard of yet.
Pay attention to keeping entry barriers low. This is a -really- important open source development principle
that, by my observations, is under appreciated by most folks. That is my -single- biggest complaint about our
use of libtool/autoconf. Let's not further complicate things further by propagating the languages required to
do a build.
>
> We haven't been using sh/sed/awk as our build platform because we
> thought those were good languages. I'm sorry, but being too busy to
> maintain the existing scripts is no excuse for rewriting them in a
> less portable language. As soon as someone has the time to write
> it in a portable language, the python should be removed.
+1
Bill
Re: apr/apr-util python dependence
Posted by Bill Stoddard <bi...@wstoddard.com>.
Roy T. Fielding wrote:
>>> However I completely disagree that Python (or Perl or PHP) is
>>> a good choice for use in build systems.
>>
>>
>> As part of the configure process, I would agree with you, but as part of
>> buildconf, I disagree--not everyone needs to run buildconf--only
>> developers, and if you're a developer, it's *really* not asking that
>> much to have Python on your dev box.
>
>
> Sure it is. If I wasn't so busy I would have vetoed the change on
> the grounds that it causes httpd to no longer be buildable by developers
> on the Cray MP. And no, I don't care whether anyone else thinks that
> is an important requirement. Creating entry barriers is what prevents
> development on new platforms that you haven't even heard of yet.
Pay attention to keeping entry barriers low. This is a -really- important open source development principle
that, by my observations, is under appreciated by most folks. That is my -single- biggest complaint about our
use of libtool/autoconf. Let's not further complicate things further by propagating the languages required to
do a build.
>
> We haven't been using sh/sed/awk as our build platform because we
> thought those were good languages. I'm sorry, but being too busy to
> maintain the existing scripts is no excuse for rewriting them in a
> less portable language. As soon as someone has the time to write
> it in a portable language, the python should be removed.
+1
Bill
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 20 Feb 2004, Patrick Welche wrote:
> On Fri, Feb 20, 2004 at 11:23:02AM +0100, Sascha Schumann wrote:
> > A shell script generating build-exports.mk is attached.
> >
> > The implementation lacks cyclic reference detection (some
> > header files point to each other). This can be resolved by
> > splitting the 2-3 header files though.
>
> You beat me to it.. I was just wondering how to do the array of
> include files which an include file includes, as per the python
> original. I reached the conclusion that that is what make is for
> isn't it? Is there a difference between
Nope. I suppose the author of the python script 'flattened'
the dependency graph to avoid cyclic dependencies:
gen-build.py:
foo.c: bar.h baz.h
gen-build.sh:
foo.c: bar.h
bar.h: baz.h
baz.h: bar.h
GNU make notices this and produces a warning.
This problem can be either resolved by splitting the header
files (I can do that if noone objects) or adding logic to
gen-build.sh.
- Sascha
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 20 Feb 2004, Patrick Welche wrote:
> On Fri, Feb 20, 2004 at 11:23:02AM +0100, Sascha Schumann wrote:
> > A shell script generating build-exports.mk is attached.
> >
> > The implementation lacks cyclic reference detection (some
> > header files point to each other). This can be resolved by
> > splitting the 2-3 header files though.
>
> You beat me to it.. I was just wondering how to do the array of
> include files which an include file includes, as per the python
> original. I reached the conclusion that that is what make is for
> isn't it? Is there a difference between
Nope. I suppose the author of the python script 'flattened'
the dependency graph to avoid cyclic dependencies:
gen-build.py:
foo.c: bar.h baz.h
gen-build.sh:
foo.c: bar.h
bar.h: baz.h
baz.h: bar.h
GNU make notices this and produces a warning.
This problem can be either resolved by splitting the header
files (I can do that if noone objects) or adding logic to
gen-build.sh.
- Sascha
Re: apr/apr-util python dependence
Posted by Patrick Welche <pr...@newn.cam.ac.uk>.
On Fri, Feb 20, 2004 at 11:23:02AM +0100, Sascha Schumann wrote:
> A shell script generating build-exports.mk is attached.
>
> The implementation lacks cyclic reference detection (some
> header files point to each other). This can be resolved by
> splitting the 2-3 header files though.
You beat me to it.. I was just wondering how to do the array of
include files which an include file includes, as per the python
original. I reached the conclusion that that is what make is for
isn't it? Is there a difference between
header.h: head1.h head2.h
foo.c: header.h
and
foo.c: header.h head1.h head2.h
? I don't think so, and it removes the most fiddly bit of the
original.. (Also I ended up using awk which you managed to do
without ;) )
Cheers,
Patrick
Re: apr/apr-util python dependence
Posted by Patrick Welche <pr...@newn.cam.ac.uk>.
On Fri, Feb 20, 2004 at 11:23:02AM +0100, Sascha Schumann wrote:
> A shell script generating build-exports.mk is attached.
>
> The implementation lacks cyclic reference detection (some
> header files point to each other). This can be resolved by
> splitting the 2-3 header files though.
You beat me to it.. I was just wondering how to do the array of
include files which an include file includes, as per the python
original. I reached the conclusion that that is what make is for
isn't it? Is there a difference between
header.h: head1.h head2.h
foo.c: header.h
and
foo.c: header.h head1.h head2.h
? I don't think so, and it removes the most fiddly bit of the
original.. (Also I ended up using awk which you managed to do
without ;) )
Cheers,
Patrick
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
A shell script generating build-exports.mk is attached.
The implementation lacks cyclic reference detection (some
header files point to each other). This can be resolved by
splitting the 2-3 header files though.
- Sascha
Re: apr/apr-util python dependence
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, March 4, 2004 10:58 AM -0800 Aaron Bannert <aa...@clove.org>
wrote:
> On Fri, Feb 20, 2004 at 11:16:10AM -0800, Justin Erenkrantz wrote:
>> It'd be trivial to have minotaur run ./buildconf before producing the
>> snapshots. This would lower the barrier of entry on the snapshots:
>> you'd no longer need autoconf, libtool, etc to use those. -- justin
>
> Isn't libtool still needed for the build process? I don't see how running
> ./buildconf would eliminate the libtool dependency.
Uh, no. When you run buildconf, libtool copies all of its files into the
tree. It's self-contained at that point. -- justin
Re: apr/apr-util python dependence
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Feb 20, 2004 at 11:16:10AM -0800, Justin Erenkrantz wrote:
> It'd be trivial to have minotaur run ./buildconf before producing the
> snapshots. This would lower the barrier of entry on the snapshots: you'd
> no longer need autoconf, libtool, etc to use those. -- justin
Isn't libtool still needed for the build process? I don't see how running
./buildconf would eliminate the libtool dependency.
-aaron
Re: apr/apr-util python dependence
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
> --On Friday, February 20, 2004 5:42 PM +0000 Ben Laurie
> <be...@algroup.co.uk> wrote:
>
>> Or even platforms you have heard of: within hours of this change I had
>> complaints from people who couldn't build snapshots in order to try out
>> mod_log_forensic...
>
>
> It'd be trivial to have minotaur run ./buildconf before producing the
> snapshots. This would lower the barrier of entry on the snapshots:
> you'd no longer need autoconf, libtool, etc to use those. -- justin
>
+1!!!
Re: apr/apr-util python dependence
Posted by Paul Querna <ch...@force-elite.com>.
On Fri, 2004-02-20 at 12:16, Justin Erenkrantz wrote:
> It'd be trivial to have minotaur run ./buildconf before producing the
> snapshots. This would lower the barrier of entry on the snapshots: you'd no
> longer need autoconf, libtool, etc to use those. -- justin
+1
Re: apr/apr-util python dependence
Posted by Sander Striker <st...@apache.org>.
On Fri, 2004-02-20 at 20:16, Justin Erenkrantz wrote:
> It'd be trivial to have minotaur run ./buildconf before producing the
> snapshots. This would lower the barrier of entry on the snapshots: you'd no
> longer need autoconf, libtool, etc to use those. -- justin
+1.
Sander
Re: apr/apr-util python dependence
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, February 20, 2004 5:42 PM +0000 Ben Laurie <be...@algroup.co.uk>
wrote:
> Or even platforms you have heard of: within hours of this change I had
> complaints from people who couldn't build snapshots in order to try out
> mod_log_forensic...
It'd be trivial to have minotaur run ./buildconf before producing the
snapshots. This would lower the barrier of entry on the snapshots: you'd no
longer need autoconf, libtool, etc to use those. -- justin
Re: apr/apr-util python dependence
Posted by Ben Laurie <be...@algroup.co.uk>.
Roy T. Fielding wrote:
>>> However I completely disagree that Python (or Perl or PHP) is
>>> a good choice for use in build systems.
>>
>>
>> As part of the configure process, I would agree with you, but as part of
>> buildconf, I disagree--not everyone needs to run buildconf--only
>> developers, and if you're a developer, it's *really* not asking that
>> much to have Python on your dev box.
>
>
> Sure it is. If I wasn't so busy I would have vetoed the change on
> the grounds that it causes httpd to no longer be buildable by developers
> on the Cray MP. And no, I don't care whether anyone else thinks that
> is an important requirement. Creating entry barriers is what prevents
> development on new platforms that you haven't even heard of yet.
Or even platforms you have heard of: within hours of this change I had
complaints from people who couldn't build snapshots in order to try out
mod_log_forensic...
Cheers,
Ben.
Re: apr/apr-util python dependence
Posted by Ben Laurie <be...@algroup.co.uk>.
Roy T. Fielding wrote:
>>> However I completely disagree that Python (or Perl or PHP) is
>>> a good choice for use in build systems.
>>
>>
>> As part of the configure process, I would agree with you, but as part of
>> buildconf, I disagree--not everyone needs to run buildconf--only
>> developers, and if you're a developer, it's *really* not asking that
>> much to have Python on your dev box.
>
>
> Sure it is. If I wasn't so busy I would have vetoed the change on
> the grounds that it causes httpd to no longer be buildable by developers
> on the Cray MP. And no, I don't care whether anyone else thinks that
> is an important requirement. Creating entry barriers is what prevents
> development on new platforms that you haven't even heard of yet.
Or even platforms you have heard of: within hours of this change I had
complaints from people who couldn't build snapshots in order to try out
mod_log_forensic...
Cheers,
Ben.
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
A shell script generating build-exports.mk is attached.
The implementation lacks cyclic reference detection (some
header files point to each other). This can be resolved by
splitting the 2-3 header files though.
- Sascha
Re: apr/apr-util python dependence
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
>> However I completely disagree that Python (or Perl or PHP) is
>> a good choice for use in build systems.
>
> As part of the configure process, I would agree with you, but as part
> of
> buildconf, I disagree--not everyone needs to run buildconf--only
> developers, and if you're a developer, it's *really* not asking that
> much to have Python on your dev box.
Sure it is. If I wasn't so busy I would have vetoed the change on
the grounds that it causes httpd to no longer be buildable by developers
on the Cray MP. And no, I don't care whether anyone else thinks that
is an important requirement. Creating entry barriers is what prevents
development on new platforms that you haven't even heard of yet.
We haven't been using sh/sed/awk as our build platform because we
thought those were good languages. I'm sorry, but being too busy to
maintain the existing scripts is no excuse for rewriting them in a
less portable language. As soon as someone has the time to write
it in a portable language, the python should be removed.
>>> So no... switching to a shell script would not be beneficial, as it
>>> would
>>> cut off future capabilities.
>>
>> I doubt that. .dsp and .dsw files are just other text files
>> which can easily be created using sh, grep, sed, tr etc.
>
> Ick. Ick ick ick ick ick. "Easily" is obviously a subjective term.
> Who
> wants to write (and, more importantly, *maintain*) hundreds (or
> thousands) of lines of /bin/sh code? Not to mention the fact that
> Python can be much more compact than /bin/sh after you hit a certain
> level of complexity.
Irrelevant to the task at hand.
> Anyway, I suppose that agreeing to disagree may be for the best here.
> Subversion has required python to run autogen.sh for years now, and
> it's
> been great for us.
Subversion has zero deployment when compared to httpd. It should
be learning lessons from httpd's history, not casting it aside.
....Roy
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
> As part of the configure process, I would agree with you, but as part of
> buildconf, I disagree--not everyone needs to run buildconf--only
> developers, and if you're a developer, it's *really* not asking that
> much to have Python on your dev box.
That must be a wonderful world where you run buildconf only
on boxes which are under your control all the time.
In reality, build system debugging is often required on
awkward systems where even a pervasive language such as perl
is often unavailable.
> Ick. Ick ick ick ick ick. "Easily" is obviously a subjective term. Who
> wants to write (and, more importantly, *maintain*) hundreds (or
> thousands) of lines of /bin/sh code?
Many people do that all the time.
> Not to mention the fact that Python can be much more compact
> than /bin/sh after you hit a certain level of complexity.
Build systems don't reach that level.
> Anyway, I suppose that agreeing to disagree may be for the best here.
Agreed. I'll rewrite the .py script on my way tonight and
submit it for review.
- Sascha
Re: apr/apr-util python dependence
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
>> However I completely disagree that Python (or Perl or PHP) is
>> a good choice for use in build systems.
>
> As part of the configure process, I would agree with you, but as part
> of
> buildconf, I disagree--not everyone needs to run buildconf--only
> developers, and if you're a developer, it's *really* not asking that
> much to have Python on your dev box.
Sure it is. If I wasn't so busy I would have vetoed the change on
the grounds that it causes httpd to no longer be buildable by developers
on the Cray MP. And no, I don't care whether anyone else thinks that
is an important requirement. Creating entry barriers is what prevents
development on new platforms that you haven't even heard of yet.
We haven't been using sh/sed/awk as our build platform because we
thought those were good languages. I'm sorry, but being too busy to
maintain the existing scripts is no excuse for rewriting them in a
less portable language. As soon as someone has the time to write
it in a portable language, the python should be removed.
>>> So no... switching to a shell script would not be beneficial, as it
>>> would
>>> cut off future capabilities.
>>
>> I doubt that. .dsp and .dsw files are just other text files
>> which can easily be created using sh, grep, sed, tr etc.
>
> Ick. Ick ick ick ick ick. "Easily" is obviously a subjective term.
> Who
> wants to write (and, more importantly, *maintain*) hundreds (or
> thousands) of lines of /bin/sh code? Not to mention the fact that
> Python can be much more compact than /bin/sh after you hit a certain
> level of complexity.
Irrelevant to the task at hand.
> Anyway, I suppose that agreeing to disagree may be for the best here.
> Subversion has required python to run autogen.sh for years now, and
> it's
> been great for us.
Subversion has zero deployment when compared to httpd. It should
be learning lessons from httpd's history, not casting it aside.
....Roy
Re: apr/apr-util python dependence
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Wed, 2004-02-18 at 05:13, Sascha Schumann wrote:
> Automake is clearly not a choice, nor has it ever been for a
> project of considerable size. And recursive make clearly
> sucks -- the PHP project got rid of it 2 years ago. We agree
> on these points.
+1
> > It was also written in Python because it is *just* starting. That script
> > will also product .dsp and .dsw files in the future (the Subversion
> > project generates these files, so I intend to follow that model). For now,
> > it is just starting: it got rid of the recursive make crap. But there is a
> > lot more that it can do.
>
> However I completely disagree that Python (or Perl or PHP) is
> a good choice for use in build systems.
As part of the configure process, I would agree with you, but as part of
buildconf, I disagree--not everyone needs to run buildconf--only
developers, and if you're a developer, it's *really* not asking that
much to have Python on your dev box.
> > So no... switching to a shell script would not be beneficial, as it would
> > cut off future capabilities.
>
> I doubt that. .dsp and .dsw files are just other text files
> which can easily be created using sh, grep, sed, tr etc.
Ick. Ick ick ick ick ick. "Easily" is obviously a subjective term. Who
wants to write (and, more importantly, *maintain*) hundreds (or
thousands) of lines of /bin/sh code? Not to mention the fact that
Python can be much more compact than /bin/sh after you hit a certain
level of complexity.
Anyway, I suppose that agreeing to disagree may be for the best here.
Subversion has required python to run autogen.sh for years now, and it's
been great for us.
-Fitz
Re: apr/apr-util python dependence
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Wed, 2004-02-18 at 05:13, Sascha Schumann wrote:
> Automake is clearly not a choice, nor has it ever been for a
> project of considerable size. And recursive make clearly
> sucks -- the PHP project got rid of it 2 years ago. We agree
> on these points.
+1
> > It was also written in Python because it is *just* starting. That script
> > will also product .dsp and .dsw files in the future (the Subversion
> > project generates these files, so I intend to follow that model). For now,
> > it is just starting: it got rid of the recursive make crap. But there is a
> > lot more that it can do.
>
> However I completely disagree that Python (or Perl or PHP) is
> a good choice for use in build systems.
As part of the configure process, I would agree with you, but as part of
buildconf, I disagree--not everyone needs to run buildconf--only
developers, and if you're a developer, it's *really* not asking that
much to have Python on your dev box.
> > So no... switching to a shell script would not be beneficial, as it would
> > cut off future capabilities.
>
> I doubt that. .dsp and .dsw files are just other text files
> which can easily be created using sh, grep, sed, tr etc.
Ick. Ick ick ick ick ick. "Easily" is obviously a subjective term. Who
wants to write (and, more importantly, *maintain*) hundreds (or
thousands) of lines of /bin/sh code? Not to mention the fact that
Python can be much more compact than /bin/sh after you hit a certain
level of complexity.
Anyway, I suppose that agreeing to disagree may be for the best here.
Subversion has required python to run autogen.sh for years now, and it's
been great for us.
-Fitz
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
Automake is clearly not a choice, nor has it ever been for a
project of considerable size. And recursive make clearly
sucks -- the PHP project got rid of it 2 years ago. We agree
on these points.
> It was also written in Python because it is *just* starting. That script
> will also product .dsp and .dsw files in the future (the Subversion
> project generates these files, so I intend to follow that model). For now,
> it is just starting: it got rid of the recursive make crap. But there is a
> lot more that it can do.
However I completely disagree that Python (or Perl or PHP) is
a good choice for use in build systems.
> So no... switching to a shell script would not be beneficial, as it would
> cut off future capabilities.
I doubt that. .dsp and .dsw files are just other text files
which can easily be created using sh, grep, sed, tr etc.
- Sascha
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
Automake is clearly not a choice, nor has it ever been for a
project of considerable size. And recursive make clearly
sucks -- the PHP project got rid of it 2 years ago. We agree
on these points.
> It was also written in Python because it is *just* starting. That script
> will also product .dsp and .dsw files in the future (the Subversion
> project generates these files, so I intend to follow that model). For now,
> it is just starting: it got rid of the recursive make crap. But there is a
> lot more that it can do.
However I completely disagree that Python (or Perl or PHP) is
a good choice for use in build systems.
> So no... switching to a shell script would not be beneficial, as it would
> cut off future capabilities.
I doubt that. .dsp and .dsw files are just other text files
which can easily be created using sh, grep, sed, tr etc.
- Sascha
Re: apr/apr-util python dependence
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 18, 2004 at 10:13:51AM +0000, Joe Orton wrote:
> On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote:
> > > requiring automake is not something I personally would be excited about... I'd
I'd -1 it right off the bat. No way on automake.
> > > like to see how bad a conversion to ordinary sh would turn out.. also, I'd
> > > guess that a conversion to the less cool but more widely
> > > ported/precompiled/preinstalled P* scripting language would be a rather quick
> > > and would not suffer greatly from uncoolness and would pick up additional
> > > people able and/or willing to maintain it ;)
> >
> > Remember that the primary focus of a build system is not ease
> > of maintenance or being written in your preferred scripting
> > language.
> >
> > No - the primary focus is being portable. That is why you
> > don't see build systems written in Perl, PHP or Python.
>
> The subject is whether Python can be required for running buildconf, not
> for running configure && make. I don't see a problem requiring Python
> for buildconf.
Exactly. buildconf is used by *developers*, not users. Tarballs won't
require Python at all to config and build them.
It was also written in Python because it is *just* starting. That script
will also product .dsp and .dsw files in the future (the Subversion
project generates these files, so I intend to follow that model). For now,
it is just starting: it got rid of the recursive make crap. But there is a
lot more that it can do.
So no... switching to a shell script would not be beneficial, as it would
cut off future capabilities.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
> The subject is whether Python can be required for running buildconf, not
> for running configure && make. I don't see a problem requiring Python
> for buildconf.
The problem with python is that it is an exotic language and
hardly installed anywhere (not everyone runs Linux). Just
requiring it for a buildconf run seems excessive to me.
Anyway, I have rewritten Perl scripts to reduce buildconf
requirements, doing the same with Python scripts should not
be any harder. :-)
- Sascha
Re: apr/apr-util python dependence
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 18, 2004 at 10:13:51AM +0000, Joe Orton wrote:
> On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote:
> > > requiring automake is not something I personally would be excited about... I'd
I'd -1 it right off the bat. No way on automake.
> > > like to see how bad a conversion to ordinary sh would turn out.. also, I'd
> > > guess that a conversion to the less cool but more widely
> > > ported/precompiled/preinstalled P* scripting language would be a rather quick
> > > and would not suffer greatly from uncoolness and would pick up additional
> > > people able and/or willing to maintain it ;)
> >
> > Remember that the primary focus of a build system is not ease
> > of maintenance or being written in your preferred scripting
> > language.
> >
> > No - the primary focus is being portable. That is why you
> > don't see build systems written in Perl, PHP or Python.
>
> The subject is whether Python can be required for running buildconf, not
> for running configure && make. I don't see a problem requiring Python
> for buildconf.
Exactly. buildconf is used by *developers*, not users. Tarballs won't
require Python at all to config and build them.
It was also written in Python because it is *just* starting. That script
will also product .dsp and .dsw files in the future (the Subversion
project generates these files, so I intend to follow that model). For now,
it is just starting: it got rid of the recursive make crap. But there is a
lot more that it can do.
So no... switching to a shell script would not be beneficial, as it would
cut off future capabilities.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
> The subject is whether Python can be required for running buildconf, not
> for running configure && make. I don't see a problem requiring Python
> for buildconf.
The problem with python is that it is an exotic language and
hardly installed anywhere (not everyone runs Linux). Just
requiring it for a buildconf run seems excessive to me.
Anyway, I have rewritten Perl scripts to reduce buildconf
requirements, doing the same with Python scripts should not
be any harder. :-)
- Sascha
Re: apr/apr-util python dependence
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote:
> > requiring automake is not something I personally would be excited about... I'd
> > like to see how bad a conversion to ordinary sh would turn out.. also, I'd
> > guess that a conversion to the less cool but more widely
> > ported/precompiled/preinstalled P* scripting language would be a rather quick
> > and would not suffer greatly from uncoolness and would pick up additional
> > people able and/or willing to maintain it ;)
> >
>
> Remember that the primary focus of a build system is not ease
> of maintenance or being written in your preferred scripting
> language.
>
> No - the primary focus is being portable. That is why you
> don't see build systems written in Perl, PHP or Python.
The subject is whether Python can be required for running buildconf, not
for running configure && make. I don't see a problem requiring Python
for buildconf.
joe
Re: apr/apr-util python dependence
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote:
> > requiring automake is not something I personally would be excited about... I'd
> > like to see how bad a conversion to ordinary sh would turn out.. also, I'd
> > guess that a conversion to the less cool but more widely
> > ported/precompiled/preinstalled P* scripting language would be a rather quick
> > and would not suffer greatly from uncoolness and would pick up additional
> > people able and/or willing to maintain it ;)
> >
>
> Remember that the primary focus of a build system is not ease
> of maintenance or being written in your preferred scripting
> language.
>
> No - the primary focus is being portable. That is why you
> don't see build systems written in Perl, PHP or Python.
The subject is whether Python can be required for running buildconf, not
for running configure && make. I don't see a problem requiring Python
for buildconf.
joe
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
> requiring automake is not something I personally would be excited about... I'd
> like to see how bad a conversion to ordinary sh would turn out.. also, I'd
> guess that a conversion to the less cool but more widely
> ported/precompiled/preinstalled P* scripting language would be a rather quick
> and would not suffer greatly from uncoolness and would pick up additional
> people able and/or willing to maintain it ;)
>
Remember that the primary focus of a build system is not ease
of maintenance or being written in your preferred scripting
language.
No - the primary focus is being portable. That is why you
don't see build systems written in Perl, PHP or Python.
- Sascha
Re: apr/apr-util python dependence
Posted by Sascha Schumann <sa...@schumann.cx>.
> requiring automake is not something I personally would be excited about... I'd
> like to see how bad a conversion to ordinary sh would turn out.. also, I'd
> guess that a conversion to the less cool but more widely
> ported/precompiled/preinstalled P* scripting language would be a rather quick
> and would not suffer greatly from uncoolness and would pick up additional
> people able and/or willing to maintain it ;)
>
Remember that the primary focus of a build system is not ease
of maintenance or being written in your preferred scripting
language.
No - the primary focus is being portable. That is why you
don't see build systems written in Perl, PHP or Python.
- Sascha
Re: apr/apr-util python dependence
Posted by Jeff Trawick <tr...@attglobal.net>.
moving to dev@apr...
Patrick Welche wrote:
> I see that good work has been done to clean up the twisty building maze
> in apr and apr-util. I suppose I want my cake and eat it - would you object
> to a translation of the two python scripts into ordinary sh, avoiding the
> need for those of us who haven't installed python to do so just for those
> two files? If anything I would prefer a dependence on automake rather than
> python.. that might make things even easier..
requiring automake is not something I personally would be excited about... I'd
like to see how bad a conversion to ordinary sh would turn out.. also, I'd
guess that a conversion to the less cool but more widely
ported/precompiled/preinstalled P* scripting language would be a rather quick
and would not suffer greatly from uncoolness and would pick up additional
people able and/or willing to maintain it ;)
Re: apr/apr-util python dependence
Posted by Jeff Trawick <tr...@attglobal.net>.
moving to dev@apr...
Patrick Welche wrote:
> I see that good work has been done to clean up the twisty building maze
> in apr and apr-util. I suppose I want my cake and eat it - would you object
> to a translation of the two python scripts into ordinary sh, avoiding the
> need for those of us who haven't installed python to do so just for those
> two files? If anything I would prefer a dependence on automake rather than
> python.. that might make things even easier..
requiring automake is not something I personally would be excited about... I'd
like to see how bad a conversion to ordinary sh would turn out.. also, I'd
guess that a conversion to the less cool but more widely
ported/precompiled/preinstalled P* scripting language would be a rather quick
and would not suffer greatly from uncoolness and would pick up additional
people able and/or willing to maintain it ;)