You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Sascha Schumann <sa...@schumann.cx> on 2004/02/22 12:37:36 UTC
updated port of gen-build.py
Here is a new adaption of gen-build.py, including the config
files.
Enjoy!
- Sascha
Re: updated port of gen-build.py
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 22, 2004 at 08:54:37PM +0100, Sander Striker wrote:
>...
> I thought we did have makefiles (or maybe it is the windows build) that
> does just that, build what is in $platform, and additionally compile all
> files in unix/ that doesn't have a counterpart in $platform.
Well, the Windows and NetWare builds are hand-maintained, so they can pull
files from wherever they want :-). In truth, this might complicate the
auto-generation of their builds. We may have to do the #include trick for
these platforms, too (or add some more logic to gen-build).
For the others, I don't recall, but I'm curious to find out more from the
people who know more than me :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: updated port of gen-build.py
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Stein wrote:
> On Sun, Feb 22, 2004 at 08:41:08AM -0500, Jeff Trawick wrote:
>
>>...
>>Should I assume that this is broken on the same platforms where gen-build.py is
>>broken (where a mix of unix and system-specific code is used)?
>
>
> Eh? I'm not sure that I understand this "brokenness" ... can you explain?
> As I understand it, if a mix is needed, then we pull in the relevant unix
> code with a .c file that simply does a #include. For example, see
> file_io/os2/fullrw.c. I don't recall that we ever had a Makefile that
> built code from *another* directory, so the only option was to use a
> #include to pull that code in.
Maybe an include trick is needed when you get some files for a feature from the
platform-specific directory and other files from the unix directory.
Example of a different situation: os390
This platform will use the atomic/os390 and dso/os390 directories but
<feature>/unix for everything else. The SUBDIRS variable in the top makefile
caused the proper sub-make to be performed.
When you mentioned something recently about a problem with platforms (foggy
memory) days, this is what I thought you meant. I guess not :)
RE: updated port of gen-build.py
Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Sunday, February 22, 2004 8:50 PM
> On Sun, Feb 22, 2004 at 08:41:08AM -0500, Jeff Trawick wrote:
> >...
> > Should I assume that this is broken on the same platforms where gen-build.py is
> > broken (where a mix of unix and system-specific code is used)?
>
> Eh? I'm not sure that I understand this "brokenness" ... can you explain?
>
> As I understand it, if a mix is needed, then we pull in the relevant unix
> code with a .c file that simply does a #include. For example, see
> file_io/os2/fullrw.c. I don't recall that we ever had a Makefile that
> built code from *another* directory, so the only option was to use a
> #include to pull that code in.
I thought we did have makefiles (or maybe it is the windows build) that
does just that, build what is in $platform, and additionally compile all
files in unix/ that doesn't have a counterpart in $platform.
But don't take my word for it...
Sander
Re: updated port of gen-build.py
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 22, 2004 at 08:41:08AM -0500, Jeff Trawick wrote:
>...
> Should I assume that this is broken on the same platforms where gen-build.py is
> broken (where a mix of unix and system-specific code is used)?
Eh? I'm not sure that I understand this "brokenness" ... can you explain?
As I understand it, if a mix is needed, then we pull in the relevant unix
code with a .c file that simply does a #include. For example, see
file_io/os2/fullrw.c. I don't recall that we ever had a Makefile that
built code from *another* directory, so the only option was to use a
#include to pull that code in.
Thanks,
-g
--
Greg Stein, http://www.lyra.org/
Re: updated port of gen-build.py
Posted by Jeff Trawick <tr...@attglobal.net>.
Sascha Schumann wrote:
>>Should I assume that this is broken on the same platforms where
>>gen-build.py is broken (where a mix of unix and system-specific
>>code is used)?
>
>
> The shell script uses similar logic, so I am afraid it might
> have similar issues as well. I suppose you refer to this
> rule deciding which objects to compile:
>
> If a particular module (mmap, memory, etc) lacks a
> platform-specific subdirectory, fall back to a generic
> implementation (which happens to be unix all the time).
> Compile all *.c files found in the selected subdirectory.
yep
actually, this issue seems to have been implemented in CVS very recently (blush!)
configure.in log shows:
Sat Feb 21 00:31:48 2004 UTC (2 days, 13 hours ago) by gstein
it looks like it builds the different OBJECTS_platform fine and hopefully picks
the correct OBJECTS_platform to build
so this issue is fixed and shouldn't be a problem for the Python or the
non-Python solution; sorry for not keeping up with things :(
Re: updated port of gen-build.py
Posted by Sascha Schumann <sa...@schumann.cx>.
> Should I assume that this is broken on the same platforms where
> gen-build.py is broken (where a mix of unix and system-specific
> code is used)?
The shell script uses similar logic, so I am afraid it might
have similar issues as well. I suppose you refer to this
rule deciding which objects to compile:
If a particular module (mmap, memory, etc) lacks a
platform-specific subdirectory, fall back to a generic
implementation (which happens to be unix all the time).
Compile all *.c files found in the selected subdirectory.
If that rule is inadequate, how would an adequate rule look
like?
For reference, I'm attaching gen-build.sh's current output.
- Sascha
Re: updated port of gen-build.py
Posted by Jeff Trawick <tr...@attglobal.net>.
Sascha Schumann wrote:
> Here is a new adaption of gen-build.py, including the config
> files.
I'll try this tomorrow on a box that I've been too lazy to install python on ;)
Should I assume that this is broken on the same platforms where gen-build.py is
broken (where a mix of unix and system-specific code is used)?
Re: updated port of gen-build.py
Posted by Jeff Trawick <tr...@attglobal.net>.
Sascha Schumann wrote:
> Here is a new adaption of gen-build.py, including the config
> files.
This works fine for me on Solaris. On z/OS (a.k.a. OS/390), I hit various make
warnings about circular dependencies with includes. After deleting all the
rules for .h file dependencies (and discovering and addressing a hole in the
libtool for httpd/apr on z/OS), I was able to build apr.