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


Reply via email to