Re: apr/apr-util python dependence
On Thu, Mar 04, 2004 at 04:03:29PM -0800, [EMAIL PROTECTED] wrote: I would double-check this personally. I just recently finished a project that asked customers to build an Apache module that depended on autoconf, automake, and libtool. Even though I ran the equivalent of buildconf, the users needed to have all three tools. That may have been because of automake, but I can't be sure and no longer have the project to double check it. Ryan It sounds to me like automake is behind that. An automake-generated Makefile.in includes rules for rebuilding configure, Makefile.in, etc. You can disable those rules for casual users by adding AM_MAINTAINER_MODE to configure.in. Of course, if your timestamps line up correctly and users don't edit Makefile.am or configure.in, it shouldn't matter. Generating a distribution with `make dist' has always produced for me a tarball independent of all autotools. If any of the autotools generate build infrastructure that requires an installation of the tool to do a plain build, that's a bug. Each is designed to generate shell scripts (autoconf, libtool) or simple, in terms of `make' features used, Makefiles (automake) to do all dirty work on the target system. -Noah
Re: apr/apr-util python dependence
I would double-check this personally. I just recently finished a project that asked customers to build an Apache module that depended on autoconf, automake, and libtool. Even though I ran the equivalent of buildconf, the users needed to have all three tools. That may have been because of automake, but I can't be sure and no longer have the project to double check it. Ryan Quoting Justin Erenkrantz [EMAIL PROTECTED]: --On Thursday, March 4, 2004 10:58 AM -0800 Aaron Bannert [EMAIL PROTECTED] 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
On Fri, 2004-03-05 at 01:03, [EMAIL PROTECTED] wrote: I would double-check this personally. I just recently finished a project that asked customers to build an Apache module that depended on autoconf, automake, and libtool. Even though I ran the equivalent of buildconf, the users needed to have all three tools. That may have been because of automake, but I can't be sure and no longer have the project to double check it. When doing releases, we take care of the buildconf step, specifically to make the tarball selfcontained. It should be rare for tarball consumers to have to re-run buildconf (happens when using a wonky libtool with vendor patches...). I would have expected more complaints if we required auto* + libtool on our target platforms. Sander
Re: apr/apr-util python dependence
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
--On Thursday, March 4, 2004 10:58 AM -0800 Aaron Bannert [EMAIL PROTECTED] 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
Justin Erenkrantz wrote: --On Friday, February 20, 2004 5:42 PM + Ben Laurie [EMAIL PROTECTED] 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
On Sun, Feb 22, 2004 at 12:54:59AM +0100, Sander Striker wrote: On Sat, 2004-02-21 at 23:19, Brad Nicholes wrote: I ran the gen-build.py script to try to understand what it is doing. I don't see how it would fit into the NetWare build process. The NetWare build is completely independant from anything that happens in mainstream build process. Just wondering how ubiquitous mkdep is and whether that would help? HISTORY The mkdep command appeared in 4.3BSD-Tahoe. (I have a feeling this dependency tracking is an old problem which must have already been solved, but presumably not in an agn-O.S.-tic way..) Cheers, Patrick
Re: apr/apr-util python dependence
On Fri, Feb 20, 2004 at 01:12:59PM -0700, Brad Nicholes wrote: The way I suspect Greg is heading is that you get a ./gen-build.py netware, which can be run on any platform to produce the things you need to do the Netware build. So this should be an improvement, since you don't have to move files, build a tool, move it back, then build. OK, now I understand it better. So I guess it's back to the religious battle. ;-) Python is just yet another build tool that we need to install. But for NetWare, getting rid of the build, copy, run, copy, continue build headache is worth it. I've checked in the modified gen-build.py, but I don't think that will help you right now since you still have NetWare-specific makefiles and other build bits. I have also committed a fix to stop doing the gen-uri-delims stuff, which I think was your real headache. We now just directly encode the tables in apr_uri.c. Once the Windows build (any what others?) stop trying to build gen_uri_delims.c/.dsp, then those files can be removed from apr-util/uri/. The next step will be to determine how gen-build.py can build NetWare build bits for you. I'm not familiar with the NetWare build system, but will look at those custom Makefiles that you have checked in. We should be able to do something. Please let me know where your pain points are now. Thanks, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
I ran the gen-build.py script to try to understand what it is doing. I don't see how it would fit into the NetWare build process. The NetWare build is completely independant from anything that happens in mainstream build process. Now that you have converted the gen-uri-delims into a static table, the only other build problems that we have are in httpd with the chartables.c and test_chars.h. Since these files are also generated by utilities, we still have the build,copy,run,copy,build problem. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Greg Stein [EMAIL PROTECTED] Friday, February 20, 2004 5:49:36 PM On Fri, Feb 20, 2004 at 01:12:59PM -0700, Brad Nicholes wrote: The way I suspect Greg is heading is that you get a ./gen-build.py netware, which can be run on any platform to produce the things you need to do the Netware build. So this should be an improvement, since you don't have to move files, build a tool, move it back, then build. OK, now I understand it better. So I guess it's back to the religious battle. ;-) Python is just yet another build tool that we need to install. But for NetWare, getting rid of the build, copy, run, copy, continue build headache is worth it. I've checked in the modified gen-build.py, but I don't think that will help you right now since you still have NetWare-specific makefiles and other build bits. I have also committed a fix to stop doing the gen-uri-delims stuff, which I think was your real headache. We now just directly encode the tables in apr_uri.c. Once the Windows build (any what others?) stop trying to build gen_uri_delims.c/.dsp, then those files can be removed from apr-util/uri/. The next step will be to determine how gen-build.py can build NetWare build bits for you. I'm not familiar with the NetWare build system, but will look at those custom Makefiles that you have checked in. We should be able to do something. Please let me know where your pain points are now. Thanks, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
On Sat, 2004-02-21 at 23:19, Brad Nicholes wrote: I ran the gen-build.py script to try to understand what it is doing. I don't see how it would fit into the NetWare build process. The NetWare build is completely independant from anything that happens in mainstream build process. The idea is that these hand maintained files also go away and are replaced with something autogenerenated, just like the windows .dsp/.vcproj files. Now that you have converted the gen-uri-delims into a static table, the only other build problems that we have are in httpd with the chartables.c and test_chars.h. Since these files are also generated by utilities, we still have the build,copy,run,copy,build problem. One step at a time. Lets get APR sorted first, then look into httpd ;). Hopefully this last step can go away for you too. Sander
Re: apr/apr-util python dependence
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
On Thu, Feb 19, 2004 at 05:55:13PM -0800, 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. httpd is still just as buildable on such platforms regardless of gen-build.py: from the release tarballs. Building from a CVS checkout cannot be done without extra tools, but that has always been true in 2.0: you need libtool and autoconf (not to mention the CVS client). Hell, autoconf itself has required Perl and GNU m4 for the last three-odd years. joe
Re: apr/apr-util python dependence
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
gen-build.sh
Description: Bourne shell script
atomic/{platform}
dso/{platform}
file_io/{platform}
locks/{platform}
memory/{platform}
misc/{platform}
mmap/{platform}
network_io/{platform}
passwd
poll/{platform}
random/{platform}
shmem/{platform}
strings
support/{platform}
tables
threadproc/{platform}
time/{platform}
user/{platform}
include/
Re: apr/apr-util python dependence
Please get your facts straight. httpd is still just as buildable on such platforms regardless of gen-build.py: from the release tarballs. Building from a CVS checkout cannot be done without extra tools, but that has always been true in 2.0: you need libtool and autoconf (not to mention the CVS client). Hell, autoconf itself has required Perl and GNU m4 for the last three-odd years. autoconf does not use perl. You are probably thinking of automake which indeed depends on perl. automake has never been used in httpd. (autoconf contains supplemental tools (autoscan.pl) for upgrades between major autoconf releases. These are not part of the normal toolchain.) Then the decision is made right there. Apache requires libtool to build from CVS. Libtool Requires Perl. libtool does not require perl. - Sascha
Re: apr/apr-util python dependence
On Fri, Feb 20, 2004 at 11:27:29AM +0100, Sascha Schumann wrote: Please get your facts straight. httpd is still just as buildable on such platforms regardless of gen-build.py: from the release tarballs. Building from a CVS checkout cannot be done without extra tools, but that has always been true in 2.0: you need libtool and autoconf (not to mention the CVS client). Hell, autoconf itself has required Perl and GNU m4 for the last three-odd years. autoconf does not use perl. It has done since 2.50 AFAIK: from the README in 2.59: Producing configuration scripts using Autoconf requires GNU M4 and Perl. You must install GNU M4 (version 1.4 or later) and Perl (5.005_03 or later) before configuring Autoconf, so that Autoconf's configure script can find them. The configuration scripts produced by Autoconf are self-contained, so their users do not need to have Autoconf (or GNU M4, Perl etc.). joe
Re: apr/apr-util python dependence
autoconf does not use perl. It has done since 2.50 AFAIK: from the README in 2.59: Fortunately, one can choose not to use the horrible autoconf 2.5x. The sane versions up to 2.13 don't require perl for buildconf'ing APR or httpd. - Sascha
Re: apr/apr-util python dependence
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
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
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
On Fri, Feb 20, 2004 at 02:17:32AM -0700, Paul Querna wrote: httpd is still just as buildable on such platforms regardless of gen-build.py: from the release tarballs. Building from a CVS checkout cannot be done without extra tools, but that has always been true in 2.0: you need libtool and autoconf (not to mention the CVS client). Hell, autoconf itself has required Perl and GNU m4 for the last three-odd years. Then the decision is made right there. Apache requires libtool to build from CVS. Libtool Requires Perl. Instead of writing it in Python, do it in Perl. Because I think the people maintaining APR would prefer Python over Perl. And the notion of well, now it doesn't build on my platform is quite suspect. The output of the process (run at buildconf time) is build-outputs.mk. Just copy that from *anywhere* to your target platform. Cheers, -g -- Greg Stein, http://www.lyra.org/
RE: apr/apr-util python dependence
From: Greg Stein [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 6:00 PM And the notion of well, now it doesn't build on my platform is quite suspect. The output of the process (run at buildconf time) is build-outputs.mk. Just copy that from *anywhere* to your target platform. We could opt to put the output of the process under version control, if that makes it easier? Sander
Re: apr/apr-util python dependence
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
Ben Laurie 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... I hate to chime in here, but I must agree. Things have certainly come a long way when the build/configure system tried to be as LCD (lowest common denominator) as possible. If we require all this extra stuff, then, at least to my mind, it means that we need to rethink not just patch. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: apr/apr-util python dependence
On Fri, Feb 20, 2004 at 01:10:06PM -0500, Jim Jagielski wrote: Ben Laurie 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... I hate to chime in here, but I must agree. Things have certainly come a long way when the build/configure system tried to be as LCD (lowest common denominator) as possible. And it was a recursive make solution which we're trying to fix. If you can come up with an LCD approach which has a single top-level Makefile, then please feel free. If we require all this extra stuff, then, at least to my mind, it means that we need to rethink not just patch. Oh, come on. For somebody building straight from CVS, to add a Python dependence? Okay, so it caught a few people unawares. We make changes like that all the time. But this one is not hard to solve. In any case, this whole notion of rewrite as a shell script just isn't going to fly. There is a lot more work that needs to happen, which I really can't see a shell script handling. As Joe Orton rightly pointed out, the build-outputs.mk output is *NOT* platform independent, yet it needs to be. We create one tarball and it goes to everybody, so that tarball (which includes build-outputs.mk) must be workable for everybody. Today, it encodes the platform of the person who generated the file. I just updated the script to generate output for all platforms (with the intent of the main Makefile selecting the right platform), but it isn't quite right. For example, it assumed that os2 wanted all the unix objects (in addition to the os2-specific objects), but that isn't right: it only wants SUBDIR/unix/ for when SUBDIR/os2/ is not specified. So I've got some logic to rework. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
On Fri, Feb 20, 2004 at 06:12:07PM +0100, Sander Striker wrote: From: Greg Stein [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 6:00 PM And the notion of well, now it doesn't build on my platform is quite suspect. The output of the process (run at buildconf time) is build-outputs.mk. Just copy that from *anywhere* to your target platform. We could opt to put the output of the process under version control, if that makes it easier? We don't put generated files in source control. We simply specify the toolchain that CVS developers need to have. That has always been a bit higher than tarball developers/users need to have. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
I am still confused as to what this all means. What do you all mean by Platform. I keep reading these email messages and it sounds like Platform == Linux. NetWare doesn't use buildconf but yet we still have to generate the files. We also don't build directly on the NetWare platform, we build on Windows and then copy to the the NLMs to NetWare. When we generate the files, we have to first build the utility, copy it to NetWare, run it and then copy the results back to windows and continue with the build. With the way that it was done before python, even though it was a pain, we could still build the utility and run it on NetWare. Python doesn't run on NetWare so we have no hope of ever running the script to generate the file. Our only option is to check the file into CVS and go through more pain trying to manually keep the file in sync. Are you going to keep gen_uri_delims.c in sync with gen-uri-delims.py so those of us that can't run python can still build? A shell script isn't possible either, since NetWare also doesn't have a shell. Our options are C, Perl or PHP. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Greg Stein [EMAIL PROTECTED] Friday, February 20, 2004 11:38:46 AM On Fri, Feb 20, 2004 at 06:12:07PM +0100, Sander Striker wrote: From: Greg Stein [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 6:00 PM And the notion of well, now it doesn't build on my platform is quite suspect. The output of the process (run at buildconf time) is build-outputs.mk. Just copy that from *anywhere* to your target platform. We could opt to put the output of the process under version control, if that makes it easier? We don't put generated files in source control. We simply specify the toolchain that CVS developers need to have. That has always been a bit higher than tarball developers/users need to have. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
On Fri, 2004-02-20 at 19:59, Jim Jagielski wrote: Greg Stein wrote: I hate to chime in here, but I must agree. Things have certainly come a long way when the build/configure system tried to be as LCD (lowest common denominator) as possible. And it was a recursive make solution which we're trying to fix. If you can come up with an LCD approach which has a single top-level Makefile, then please feel free. If we require all this extra stuff, then, at least to my mind, it means that we need to rethink not just patch. Oh, come on. For somebody building straight from CVS, to add a Python dependence? Okay, so it caught a few people unawares. We make changes like that all the time. But this one is not hard to solve. In any case, this whole notion of rewrite as a shell script just isn't going to fly. :) No, I have no solutions, nor did I mean to imply that: o Such a solution is trivial o That the solution used was done with no thought of impact to developers. Thanks Jim, for being explicit with that. I think this thread needed some of that explicitness, since it is beginning to show agitation across the board with the participants. I think there is a lot of potential to get religous in this thread, and that is indeed not where we want to go. Now, if we were using Subversion I would suggest that Greg create a branch, code the lot up, and then merge the final build system back. Heck, I'll even suggest that while using CVS. When a similar build system was introduced for Subversion, it broke builds for at least some developers. It took a bit of effort to get the problems out, but it was worth it. If we are going in this direction, and I prefer we do, (if only for the sake to see where this goes) I'd like to see it happen on a branch, so that the migration can be smooth instead of clunky accompagnied with lots of chagrin. Sander
Re: apr/apr-util python dependence
--On Friday, February 20, 2004 5:42 PM + Ben Laurie [EMAIL PROTECTED] 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
On Fri, Feb 20, 2004 at 11:50:55AM -0700, Brad Nicholes wrote: I am still confused as to what this all means. What do you all mean by Platform. I keep reading these email messages and it sounds like Platform == Linux. The Platform will be NetWare. The gen-build script should be able to generate the NetWare build items from any platform. Thus, you should be able to run it on Windows, where you do the rest of your build. ... file in sync. Are you going to keep gen_uri_delims.c in sync with gen-uri-delims.py so those of us that can't run python can still build? I'm going to toss both generation scripts. The need to have a program at build time was to pick up whether the platform was ASCII or EBCDIC, but we can easily do that with a #ifdef at compilation time of apr_uri.c. When I converted gen_uri_delims.c (to simplify the overall build process), I had not thought about EBCDIC. Jeff reminded me, so my fix was to fix apr_uri rather than poke at the gen-uri stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
On Fri, 2004-02-20 at 19:50, Brad Nicholes wrote: I am still confused as to what this all means. What do you all mean by Platform. I keep reading these email messages and it sounds like Platform == Linux. NetWare doesn't use buildconf but yet we still have to generate the files. We also don't build directly on the NetWare platform, we build on Windows and then copy to the the NLMs to NetWare. When we generate the files, we have to first build the utility, copy it to NetWare, run it and then copy the results back to windows and continue with the build. With the way that it was done before python, even though it was a pain, we could still build the utility and run it on NetWare. Python doesn't run on NetWare so we have no hope of ever running the script to generate the file. Our only option is to check the file into CVS and go through more pain trying to manually keep the file in sync. Are you going to keep gen_uri_delims.c in sync with gen-uri-delims.py so those of us that can't run python can still build? A shell script isn't possible either, since NetWare also doesn't have a shell. Our options are C, Perl or PHP. The way I suspect Greg is heading is that you get a ./gen-build.py netware, which can be run on any platform to produce the things you need to do the Netware build. So this should be an improvement, since you don't have to move files, build a tool, move it back, then build. Sander
Re: apr/apr-util python dependence
On Fri, Feb 20, 2004 at 01:59:28PM -0500, Jim Jagielski wrote: ... No, I have no solutions, nor did I mean to imply that: o Such a solution is trivial o That the solution used was done with no thought of impact to developers. Well, thought *was* applied, but to be honest, I/we obviously we missed some things. Like Joe's point about platform independence for the output (my simplest answer is that I didn't run into that with svn since it is built on top of APR, so there *were* no platform specifics other than the type of output (e.g. makefile vs dsp)). The gen-uri-delim was effectively a separate change, and that one forgot about EBCDIC and also created a pain for Brad's NetWare build. I'm working on a solution for the former, and have a solution (to-be-coded) for the latter. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
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
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
The way I suspect Greg is heading is that you get a ./gen-build.py netware, which can be run on any platform to produce the things you need to do the Netware build. So this should be an improvement, since you don't have to move files, build a tool, move it back, then build. OK, now I understand it better. So I guess it's back to the religious battle. ;-) Python is just yet another build tool that we need to install. But for NetWare, getting rid of the build, copy, run, copy, continue build headache is worth it. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: apr/apr-util python dependence
--On Sunday, February 15, 2004 1:06 PM -0500 Jeff Trawick [EMAIL PROTECTED] 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
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
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
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
On Wed, Feb 18, 2004 at 10:13:51AM +, 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
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
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
moving to [EMAIL PROTECTED] 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 ;)
