You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Aryeh Katz <ar...@secured-services.com> on 2004/02/06 16:44:38 UTC
frustrating build experience *nix/windows
I'd like to report a frustrating build experience, that is primarily a
windows issue, but it highlights a 1.3/2.0 change.
In the 1.3 environment I was able to use the --shadow configure option
to use the same source tree for multiple os's. This was quite valuable,
as one source code change was needed for all platforms.
However, the --shadow option is gone in 2.0. That means I had to use
--srcdir to accomplish the same results. All was fine until I came to
windows. Then things blew up. Once I did my windows build, my unix build
started pulling in all sorts of windows defines, despite the fact that
it should have been using the os's include files. I tried to clean it
up, but ended up just having to remove the whole tree, and start all
over again.
And I think I'm not the only one that has this problem. I think everyone
does. That's why there are two source packages, windows and UNIX.
Can someone tell me why the --shadow option was removed?
Aryeh
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2
Re: frustrating build experience *nix/windows
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:43 AM 2/9/2004, you wrote:
>William A. Rowe, Jr. wrote:
>
>>If I grok what you are asking....
>>.... it would be nice if win32, too, would support VPATH builds with a --srcdir
>>like argument - and throw it's generated files in another directory tree.
>>Did I get the point? This seems doable.
>That would be perfect.
>Do I need to bugzilla this?
By rights you should - but I'm already on it as part of revisiting the Win32
build schema (because enabling APR features like IPV6 and httpd conditional
features like zlib/mod_deflate and openssl/mod_ssl is difficult today.) It's just
one more (worthy) feature to include in win32 specifics.
Bill
Re: frustrating build experience *nix/windows
Posted by Aryeh Katz <ar...@secured-services.com>.
William A. Rowe, Jr. wrote:
> If I grok what you are asking....
>
> .... it would be nice if win32, too, would support VPATH builds with a --srcdir
> like argument - and throw it's generated files in another directory tree.
>
> Did I get the point? This seems doable.
>
That would be perfect.
Do I need to bugzilla this?
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2
Re: frustrating build experience *nix/windows
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
If I grok what you are asking....
.... it would be nice if win32, too, would support VPATH builds with a --srcdir
like argument - and throw it's generated files in another directory tree.
Did I get the point? This seems doable.
Bill
At 12:44 PM 2/6/2004, you wrote:
>William A. Rowe, Jr. wrote:
>
>>At 09:44 AM 2/6/2004, Aryeh Katz wrote:
>>
>>>In the 1.3 environment I was able to use the --shadow configure option to use the same source tree for multiple os's. This was quite valuable, as one source code change was needed for all platforms.
>>>However, the --shadow option is gone in 2.0.
>>
>>....
>>
>>>That's why there are two source packages, windows and UNIX.
>>
>>Actually that's not the reason. The two reasons are:
>>1. line endings; msvc and msdev studio hate several files with unix line endings
>> and either fail all together (nmake makefile) or produce erroneous results
>> (emitted diagnostic line numbers from .c source files etc.) The win32 package
>> uses srclib/apr/build/lineends.pl to mop text files from one to the other form.
>> Unless you are using a linux toolchain, or working on a volume that supports
>> two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this
>> issue seems that it would continue to plague you.
>This might be the issue *nix to windows. I was having trouble the other direction. After my windows builds my *nix builds were toast.
>>2. build files; this shouldn't be a hassle for you, it simply includes generated
>> win32 exported makefiles and makefile dependencies from .pdb projects, along with the awk result .rc version files. These aren't present in the
>> Unix build, and are honestly not required to build the project if you use
>> Visual Studio later than version 5.
>Actually, this was exactly my problem.
>apr.h, apu.h and a whole bunch of other files were generated by windows (and at least I couldn't get it to clean up). Once those header files get included by the *nix packages (despite the fact they have working apr.h etc in their own tree), the sources won't compile.
>--
>Aryeh Katz
>SecureD Services
>http://www.secured-services.com/
>410 653 0700 x 2
Re: frustrating build experience *nix/windows
Posted by Aryeh Katz <ar...@secured-services.com>.
William A. Rowe, Jr. wrote:
> At 09:44 AM 2/6/2004, Aryeh Katz wrote:
>
>>In the 1.3 environment I was able to use the --shadow configure option to use the same source tree for multiple os's. This was quite valuable, as one source code change was needed for all platforms.
>>However, the --shadow option is gone in 2.0.
>
>
> ....
>
>
>>That's why there are two source packages, windows and UNIX.
>
>
> Actually that's not the reason. The two reasons are:
>
> 1. line endings; msvc and msdev studio hate several files with unix line endings
> and either fail all together (nmake makefile) or produce erroneous results
> (emitted diagnostic line numbers from .c source files etc.) The win32 package
> uses srclib/apr/build/lineends.pl to mop text files from one to the other form.
> Unless you are using a linux toolchain, or working on a volume that supports
> two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this
> issue seems that it would continue to plague you.
>
This might be the issue *nix to windows. I was having trouble the other
direction. After my windows builds my *nix builds were toast.
> 2. build files; this shouldn't be a hassle for you, it simply includes generated
> win32 exported makefiles and makefile dependencies from .pdb projects,
> along with the awk result .rc version files. These aren't present in the
> Unix build, and are honestly not required to build the project if you use
> Visual Studio later than version 5.
>
>
Actually, this was exactly my problem.
apr.h, apu.h and a whole bunch of other files were generated by windows
(and at least I couldn't get it to clean up). Once those header files
get included by the *nix packages (despite the fact they have working
apr.h etc in their own tree), the sources won't compile.
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2
Re: frustrating build experience *nix/windows
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:44 AM 2/6/2004, Aryeh Katz wrote:
>In the 1.3 environment I was able to use the --shadow configure option to use the same source tree for multiple os's. This was quite valuable, as one source code change was needed for all platforms.
>However, the --shadow option is gone in 2.0.
....
>That's why there are two source packages, windows and UNIX.
Actually that's not the reason. The two reasons are:
1. line endings; msvc and msdev studio hate several files with unix line endings
and either fail all together (nmake makefile) or produce erroneous results
(emitted diagnostic line numbers from .c source files etc.) The win32 package
uses srclib/apr/build/lineends.pl to mop text files from one to the other form.
Unless you are using a linux toolchain, or working on a volume that supports
two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this
issue seems that it would continue to plague you.
2. build files; this shouldn't be a hassle for you, it simply includes generated
win32 exported makefiles and makefile dependencies from .pdb projects,
along with the awk result .rc version files. These aren't present in the
Unix build, and are honestly not required to build the project if you use
Visual Studio later than version 5.
>Can someone tell me why the --shadow option was removed?
Not I - other than we ditched our over-abused configure script in favor of
autoconf's inherent features. As you suggest, --srcdir does the same thing.
Bill