Roumen Petrov wrote:
> Charles Wilson wrote:
>> On 11/29/2011 5:28 PM, Roumen Petrov wrote:
>>> Ralph Engels wrote:
>>> a) http://bugs.python.org/issue3754
>>> b) http://bugs.python.org/issue3871
>>> you could get patches for more up to date versions.
>> Those are for mingw builds (e.g. use msvcrt runtime library). An msys
>> python would be more similar to a cygwin build.
> I never test cpython build in msys build(!) environment .
> a) msys or mingw
> cpython bug tracking system has some request and ... I don't know what
> to say .
> For instance 'MSYS build fails with `S_IXGRP' undeclared' (http: //
> bugs.python.org / issue9098) .
> I don't think that this is related to msys . In the patch we will see
> "if def __MINGW32__ " , i.e. I think that reporter mix environment with
> build host . It is difficult to distinguish which one is actually msys
> build related.
#ifdef __MINGW32__ is correct. MSYS provides a build environment for
__MINGW32__ by default. However, I can change the build environment to
__MSYS__ for development of MSYS which is what Ralph is doing.
> b) .... (no title)
> preface: In my list is this one " Makefile.pre.in contains extra
> slash before $(DESTDIR) which can cause Cygwin build to fail"( http: //
> bugs.python.org / issue2233) . Actually report it is about install
> phase. Issue is reported when I have a cygwin build environment (2008)
> and I remember one issue. Three years later is difficult to remember
> exact failure ... may be some regression tests fail.
DESTDIR typically will not work for Windows environments. We typically
will see something like ``cp c:/build/foo c:/destdir/c:/prefix'' which
isn't anywhere near correct. We give the workaround to redefine prefix
during the install like so ``make install prefix=c:/destdir/prefix''.
There are a small number of packages that might rebuild with the new
prefix but the GNU Coding Standard says (or at least used to say) that a
package should not rebuild when a different prefix is given during the
> I will try to explain issue b)
> Program name under cygwin is without .exe suffix , i.e. just python .
> Real program name is with suffix. In the build directory exist
> subdirectory with name Python.
> So in build exist python.exe and Python. Next is one of he python
> library functions, probably getpath(), that will try find location of
> python executable. Processing list of paths function append name of
> program and check is exist executable is current path -may with call of
> stat function with flag that check if is a regular file . Result is no
> as actually xxx/Python is a directory (note case insensitive file
> system) . As result python executable cannot be found and ....
> Now I cannot remember result .
> c) $(PYTHON) in Makefile.pre.in
> Lets return to my cross patch "issue 3754" .
> The original make file has lines like this
> "if test -f $(DESTDIR)$(BINDIR)/$(PYTHON)$(VERSION)$(EXE)"
> and in make file $(PYTHON) is defined as python$(EXE) so the test is for
> May be issue is only for python 3+ builds .
> Impacts is on all system with suffix for executable .
I don't expect package maintainers will ever get this correct. It will
mean that $(BINDIR) needs to be mucked to remove D: from the value
before appending it to the value of $(DESTIDR).
> d) cygwin use unixcompiler
> Exist one request "Use The CygwinCCompiler Under Cygwin" (http: //
> bugs.python.org / issue2445) .
> Since 2001 cygwin build is based on unix compiler class . This class
> cannot found xxxFOO.dll.a (import) libraries and also cannot found
> library if xxx is not lib
> The mingw additional patch from issue3871 will add one work around to
> CygwinCCompiler compiler but ... Lets say it is a work around could help
> to minimize reports from users that just start to use XXXX build
> environment . It is not solution .
I haven't used Cygwin proper for many years. I have no idea what a
CygwinCCompiler is. Your xxxFoo.dll.a should be libFoo.dll.a but it
could reference cygFoo.dll or probably more like cygFoo-1.dll so
xxxFoo.dll.a could be libcygFoo.dll.a. The reasons for the prefix are good.
> e) sys.platfrom
> Question is how to announce msys as python platform ?
> You could use MACHDEP to "msys" on configure command line . Note command
> line !
> Of course user could use environment after patch from issue http: //
> bugs.python.org / issue3718 .
> Result will be that sys.platform will return msys . Now scan sources and
> add msys where cygwin is found.
If the user is in a MinGW build environment returning msys would not be
correct. The sys.platform should be set via ``uname -s'' and if uname
executable is not on PATH default to mingw or abort if uname doesn't
exist and MACHDEP isn't given on the command line.