Re: Windows build - Bug fixes for "out of cygwin build".

David Genest wrote:

> Because of my attempt to build on multiple environments in-cygwin,
> out-of-cygwin, I was under the impression that the configure scripts of
> the last run in one environment was interfering on the other. I wanted
> to make sure that it was not the case, thus adding a clean option. While
> refactoring this, I felt that the new structure would help expand in the
> future. The addition of the option was made to remove code duplication.

calling 'autogen.sh' will generate various configure scripts. That process
is independent of the build platform, i.e. there is no interference.
It's what these scripts generate (Makefiles, acconfig.hh, etc.) that is
specific to a particular platform, but these end up in platform-specific
build trees anyway.

>     >  case `uname -s` in
>     >  CYGWIN*)
>     > @@ -91,7 +91,7 @@
>     >        if test "$CXX" == "g++"; then
>     >          CPPFLAGS="$CPPFLAGS -D PARSE_MSVC"
>     >          CFLAGS="-mno-cygwin $CFLAGS"
>     > -        CXXFLAGS="-mno-cygwin $CXXFLAGS"
>     > +        CXXFLAGS="-mno-cygwin -D_WIN32 $CXXFLAGS"
> 
>     This looks wrong. The compiler should predefine a platform macro. If it
>     isn't _WIN32, we need to check for something else. To see what macros
>     are predefined, you can use 'g++ -v -dD -E ...' (just what we do when
>     invoking gcc from the Emulator module).
> 
> 
> Ok, if this is wrong, where should I put the define ? The Path.cc file
> needs to be aware of the correct define in order to select the
> path-win32.cc or path-posix.cc . Anyway, as someone is already porting
> to boost::filesystem, the problem will go away. But there might be other
> places where we need this information. I'm not sure I understand the way
> you suggest of finding that out.

Try running "g++ -v -dD -E some_input.cc" and "g++ -mno-cygwin -v -dD -E some_input.cc"
in a cygwin shell, and look at the listing(s) of predefined macros. It is these
macros that we should use to mask code, not macros we have to explicitely
add via the command line.
I thought _WIN32 (or some variant thereof) was already predefined with "g++ -mno-cygwin".
Is that not the case ?

>     >        tmp_man_dir = os.path.abspath (os.path.join(self.build_temp,
>     > -                                                 'doc/Manual'))
>     > +                                                
>     'Release/doc/Manual'))
> 
>     I'm not sure about that one. Is the original path wrong ? (I remember
>     having seen 'Release/' as part of some path when building on
>     windows, but
>     probably only in the compilation of the code, not the doc
>     generation. So is
>     this for consistency only ? Also, you seem to make this change
>     irrespectively
>     of the platform. This should be 'nt' only, no ?)
> 
> 
> When I  tried debugging,  I saw that the all the outputs were not made
> at the same place. There was a Release prefix in my build. I thought it
> was needed, but you are right, I was careless about the platform. We
> should: remove the Release/ prefix, or add a special case. I prefer the
> former. I do not know where the Release/ prefix comes from.

OK. I notice some parts of the python distutils system includes a 'Release'
sub-directory. If in some place this is missing we may want to fix it, for
consistency, so the entire build ends up in a single root directory.

> You will probably need the major part of the fix for the multiplatform
> support of the doc build.

OK.



>     > -            syn_cxx = '`cygpath -a %s/src`'%os.path.abspath(
>     self.build_ctemp)
>     > -            syn_cxx = syn_cxx.replace('\\', '\\\\\\\\\\\\\\\\')
>     > +            syn_cxx = '`cygpath -a
>     \"%s/src\"`'%os.path.abspath(self.build_ctemp)
> 
>     Same here. I'm surprized this works (though I would love to be able
>     to throw away
>     all this multi-escaping. It's so ugly.)
> 
> 
> It turns out that the \ is not needed (because escaping " with \" does
> nothing: ie: print 'this is \"a test\"' yields the same as: print 'this
> is "a test"'). But the double quote is.
> for example, without the double quotes, when I encounter this (taken
> from the python setup.py setup output):
> C:\bin\cygwin\bin\sh.exe -c "../../../src/configure --prefix=\"`cygpath
> -a c:\bin\Python25`\" --with-python=\"`cygpath -a
> c:\bin\Python25`/python.exe\"
> later, the script dies saying that "../../../src/configure: line 4294:
> /cygdrive/c/binPython25/python.exe: No such file or directory". Someone
> is clearly using the backslashes as escapes. If you use my change
> (without escaping), this error goes away, and you don't need the ugly
> \\\\\\\\\\\\\ patch.
> 
>  I added locally the quotes fix on the latest revision (1827)  of
> setup.py and everything builds. The "| tr" fix does the job, and no
> other change is needed in the .ac files.

Excellent.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...