Adding win32/GNUmakefile

[p5pRT]

Migrated from rt.perl.org#123440 (status was 'resolved')

Searchable as RT123440$

[p5pRT]

From @kmx

Created by @kmx

With ExtUtils​::MakeMaker v7 there is an option to use GNU make on
MS Windows instead of traditional dmake.

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

If you find it a good idea I am ready to do the work.

Thanks

--
kmx

Perl Info

Flags:
     category=core
     severity=low

Site configuration information for perl 5.20.1:

Configured by strawberry-perl at Mon Sep 15 13:28:28 2014.

Summary of my perl5 (revision 5 version 20 subversion 1) configuration:

   Platform:
     osname=MSWin32, osvers=6.3, archname=MSWin32-x64-multi-thread
     uname='Win32 strawberry-perl 5.20.1.1 #1 Mon Sep 15 13:26:45 2014 x64'
     config_args='undef'
     hint=recommended, useposix=true, d_sigaction=undef
     useithreads=define, usemultiplicity=define
     use64bitint=define, use64bitall=undef, uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='gcc', ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE 
-DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS 
-DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields',
     optimize='-s -O2',
     cppflags='-DWIN32'
     ccversion='', gccversion='4.8.3', gccosandvers=''
     intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
     ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long 
long', lseeksize=8
     alignbytes=8, prototype=define
   Linker and Libraries:
     ld='g++.exe', ldflags ='-s -L"C:\tmp64\perl\lib\CORE" -L"C:\tmp64\c\lib"'
     libpth=C:\tmp64\c\lib C:\tmp64\c\x86_64-w64-mingw32\lib 
C:\tmp64\c\lib\gcc\x86_64-w64-mingw32\4.8.3
     libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
     perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
     libc=, so=dll, useshrplib=true, libperl=libperl520.a
     gnulibc_version=''
   Dynamic Linking:
     dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' '
     cccdlflags=' ', lddlflags='-mdll -s -L"C:\tmp64\perl\lib\CORE" 
-L"C:\tmp64\c\lib"'



@INC for perl 5.20.1:
     C:/tmp64/perl/site/lib
     C:/tmp64/perl/vendor/lib
     C:/tmp64/perl/lib
     .


Environment for perl 5.20.1:
     HOME=C:\tmp64\data
     LANG (unset)
     LANGUAGE (unset)
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
PATH=C:\tmp64\perl\site\bin;C:\tmp64\perl\bin;C:\tmp64\c\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
     PERL_BADLANG (unset)
     SHELL (unset)

[p5pRT]

From @steve-m-hay

On Tue Dec 16 00​:49​:53 2014, kmxx wrote​:

This is a bug report for perl from kmx@​atlas.cz,
generated with the help of perlbug 1.40 running under perl 5.20.1.

-----------------------------------------------------------------
[Please describe your issue here]

With ExtUtils​::MakeMaker v7 there is an option to use GNU make on
MS Windows instead of traditional dmake.

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

If you find it a good idea I am ready to do the work.

Sounds like a good idea to me, except for slight concerns over maintenance troubles. We already have two makefiles (three if you count WinCE) in win32/, which often both need to have similar patches applied. Would you envisage adding a third flavour to the mix, or *replacing* the dmake makefile.mk with your new GNUmakefile?

The latter would be preferable from a maintenance viewpoint, but I don't know how many people would be inconvenienced by dropping dmake. Probably not a huge number since it's fairly obscure and GNU make is readily available anyway.

If there was any way to have some means of (re)generating the two makefiles from some common code (I'm thinking of a "regen" step that porters can run when making changes to makefiles; perl distros would still be shipped with both versions in them) then that would be great (and conceivably we could then even keep on dmake support since it *might* not be such an extra overhead). I've always wanted to have a look at doing this, but I've never found the time. If this was part of your plan then that would be awesome; if not then it's not a problem if we end up with two makefiles like we have now -- the "regen" idea can still be done sometime in the future.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @kmx

On 16.12.2014 10​:23, Steve Hay via RT wrote​:

On Tue Dec 16 00​:49​:53 2014, kmxx wrote​:

This is a bug report for perl from kmx@​atlas.cz,
generated with the help of perlbug 1.40 running under perl 5.20.1.

-----------------------------------------------------------------
[Please describe your issue here]

With ExtUtils​::MakeMaker v7 there is an option to use GNU make on
MS Windows instead of traditional dmake.

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

If you find it a good idea I am ready to do the work.

Sounds like a good idea to me, except for slight concerns over maintenance troubles. We already have two makefiles (three if you count WinCE) in win32/, which often both need to have similar patches applied. Would you envisage adding a third flavour to the mix, or *replacing* the dmake makefile.mk with your new GNUmakefile?

The latter would be preferable from a maintenance viewpoint, but I don't know how many people would be inconvenienced by dropping dmake. Probably not a huge number since it's fairly obscure and GNU make is readily available anyway.

If there was any way to have some means of (re)generating the two makefiles from some common code (I'm thinking of a "regen" step that porters can run when making changes to makefiles; perl distros would still be shipped with both versions in them) then that would be great (and conceivably we could then even keep on dmake support since it *might* not be such an extra overhead). I've always wanted to have a look at doing this, but I've never found the time. If this was part of your plan then that would be awesome; if not then it's not a problem if we end up with two makefiles like we have now -- the "regen" idea can still be done sometime in the future.

My suggestion is to​:
1/ have both GNUmakefile + makefile.mk in 5.22 (May 2015)
2/ (maybe) drop makefile.mk in 5.24 (May 2016)

The other thing is that makefile.mk supports also msvc whereas my plan for
GNUmakefile is to support gcc only.

I am not sure if I can say something about "regen" idea. Maybe let's first
have "some" GNUmakefile then we can analyse if some parts may be generated
or not.

--
kmx

[p5pRT]

From @steve-m-hay

On 16 December 2014 at 09​:39, kmx <kmx@​atlas.cz> wrote​:

On 16.12.2014 10​:23, Steve Hay via RT wrote​:

On Tue Dec 16 00​:49​:53 2014, kmxx wrote​:

This is a bug report for perl from kmx@​atlas.cz,
generated with the help of perlbug 1.40 running under perl 5.20.1.

-----------------------------------------------------------------
[Please describe your issue here]

With ExtUtils​::MakeMaker v7 there is an option to use GNU make on
MS Windows instead of traditional dmake.

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

If you find it a good idea I am ready to do the work.

Sounds like a good idea to me, except for slight concerns over maintenance
troubles. We already have two makefiles (three if you count WinCE) in
win32/, which often both need to have similar patches applied. Would you
envisage adding a third flavour to the mix, or *replacing* the dmake
makefile.mk with your new GNUmakefile?

The latter would be preferable from a maintenance viewpoint, but I don't
know how many people would be inconvenienced by dropping dmake. Probably not
a huge number since it's fairly obscure and GNU make is readily available
anyway.

If there was any way to have some means of (re)generating the two
makefiles from some common code (I'm thinking of a "regen" step that porters
can run when making changes to makefiles; perl distros would still be
shipped with both versions in them) then that would be great (and
conceivably we could then even keep on dmake support since it *might* not be
such an extra overhead). I've always wanted to have a look at doing this,
but I've never found the time. If this was part of your plan then that would
be awesome; if not then it's not a problem if we end up with two makefiles
like we have now -- the "regen" idea can still be done sometime in the
future.

My suggestion is to​:
1/ have both GNUmakefile + makefile.mk in 5.22 (May 2015)
2/ (maybe) drop makefile.mk in 5.24 (May 2016)

Ok, sounds reasonable to me. It means that we'll have three makefiles
to maintain for a while, but it won't be for too long.

The other thing is that makefile.mk supports also msvc whereas my plan for
GNUmakefile is to support gcc only.

I think that's reasonable too. Unless we ever switch over to GNU make
entirely and drop nmake support (which I don't see happening any time
soon, if at all, since nmake is the obvious choice for VC++ users)
then there's little point in GNUmakefile also supporting VC++. In
theory it might occasionally be useful to try a VC++ build with a
different make tool in case of some suspected problem with nmake, but
in practice I can't think of an occasion that I've ever done that with
the existing dmake makefile.mk. I've only ever built using VC++/nmake
and gcc/dmake.

I am not sure if I can say something about "regen" idea. Maybe let's first
have "some" GNUmakefile then we can analyse if some parts may be generated
or not.

Yes, creating a regen script will be much easier when we can see the
GNUmakefile that we're trying to generate :-)

[p5pRT]

From @Leont

On Tue, Dec 16, 2014 at 9​:49 AM, kmx <perlbug-followup@​perl.org> wrote​:

With ExtUtils​::MakeMaker v7 there is an option to use GNU make on
MS Windows instead of traditional dmake.

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

If you find it a good idea I am ready to do the work.

I had proposed just that in #121214. Given the state of dmake I'd prefer
this happening yesterday. I suspect making it support both gcc and msvc
would be feasable, given we already have the logic (it just needs
translation).

Leon

[p5pRT]

From @jandubois

On Tue, Dec 16, 2014 at 7​:14 AM, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Tue, Dec 16, 2014 at 9​:49 AM, kmx <perlbug-followup@​perl.org> wrote​:

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

I had proposed just that in #121214. Given the state of dmake I'd prefer
this happening yesterday.

+1

I suspect making it support both gcc and msvc
would be feasable, given we already have the logic (it just needs
translation).

Is there any benefit to it? I actually prefer to limit the variation
in build tools, i.e. either use VC/nmake, or GCC/GNUmake for building
Perl and modules. Supporting different make utilities with different
compilers just adds complexities in modules down the toolchain with no
obvious (to me) benefit.

Cheers,
-Jan

[p5pRT]

From @kmx

On 16.12.2014 20​:08, Jan Dubois wrote​:

On Tue, Dec 16, 2014 at 7​:14 AM, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Tue, Dec 16, 2014 at 9​:49 AM, kmx <perlbug-followup@​perl.org> wrote​:

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

I had proposed just that in #121214. Given the state of dmake I'd prefer
this happening yesterday.
+1

Sorry, I should have done better research. These tickets can be merged.

I suspect making it support both gcc and msvc
would be feasable, given we already have the logic (it just needs
translation).
Is there any benefit to it? I actually prefer to limit the variation
in build tools, i.e. either use VC/nmake, or GCC/GNUmake for building
Perl and modules. Supporting different make utilities with different
compilers just adds complexities in modules down the toolchain with no
obvious (to me) benefit.

I agree with keeping separate makefiles for 1/ VC+nmake and 2/ GCC+GNUmake.

Here is the first version - https://gist.github.com/kmx/b5805847b6485c5c3a65
Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32 subdir.
It seems to work but definitely needs thorough testing.

--
kmx

[p5pRT]

From @sisyphus

-----Original Message-----
From​: kmx
Sent​: Thursday, December 18, 2014 2​:07 AM
To​: perl5-porters@​perl.org
Subject​: Re​: [perl #123440] Adding win32/GNUmakefile

Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32
subdir.
It seems to work but definitely needs thorough testing.

Nice !!
I'll certainly be using this makefile to build 5.21.7 (and various perl
extensions) when it comes out.

I take it that the GNU make utility must be named 'gmake' - that using a GNU
make utility of any other name (eg 'mingw32-make' or 'make') is disallowed.
I think this should be spelled out clearly somewhere .... that is, of
course, if it hasn't *already* been done :-)

Cheers,
Rob

[p5pRT]

From @Leont

On Wed, Dec 17, 2014 at 4​:07 PM, kmx <kmx@​atlas.cz> wrote​:

Here is the first version -
https://gist.github.com/kmx/b5805847b6485c5c3a65
Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32
subdir.
It seems to work but definitely needs thorough testing.

Line 323 is wrong (should be a ifneq), other than that it looks good to me.

Leon

[p5pRT]

From @jandubois

On Wed, Dec 17, 2014 at 3​:06 PM, <sisyphus1@​optusnet.com.au> wrote​:

I take it that the GNU make utility must be named 'gmake' - that using a GNU
make utility of any other name (eg 'mingw32-make' or 'make') is disallowed.

I see that 'gmake' is hard-coded in one place, but replacing that with
$(MAKE) should make it work for any name, no?

Cheers,
-Jan

[p5pRT]

From @Leont

On Thu, Dec 18, 2014 at 12​:30 AM, Jan Dubois <jand@​activestate.com> wrote​:

On Wed, Dec 17, 2014 at 3​:06 PM, <sisyphus1@​optusnet.com.au> wrote​:

I take it that the GNU make utility must be named 'gmake' - that using a
GNU
make utility of any other name (eg 'mingw32-make' or 'make') is
disallowed.

I see that 'gmake' is hard-coded in one place, but replacing that with
$(MAKE) should make it work for any name, no?

That's just the configuration value. It's telling MakeMaker what brand of
make you're using (on Unix it's always "make"), but shouldn't be used
otherwise AFAIK.

Leon

[p5pRT]

From @craigberry

On Wed, Dec 17, 2014 at 5​:40 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

On Thu, Dec 18, 2014 at 12​:30 AM, Jan Dubois <jand@​activestate.com> wrote​:

On Wed, Dec 17, 2014 at 3​:06 PM, <sisyphus1@​optusnet.com.au> wrote​:

I take it that the GNU make utility must be named 'gmake' - that using a
GNU
make utility of any other name (eg 'mingw32-make' or 'make') is
disallowed.

I see that 'gmake' is hard-coded in one place, but replacing that with
$(MAKE) should make it work for any name, no?

That's just the configuration value. It's telling MakeMaker what brand of
make you're using (on Unix it's always "make"), but shouldn't be used
otherwise AFAIK.

It looks to me like $(MAKE) is a built-in variable and will expand to
whatever make you're actually running​:

$ make -p | grep MAKE_COMMAND
make​: *** No targets specified and no makefile found. Stop.
MAKE = $(MAKE_COMMAND)
MAKE_COMMAND := /Applications/Xcode.app/Contents/Developer/usr/bin/make

That's GNU make 3.81.

[p5pRT]

From @jandubois

On Wed, Dec 17, 2014 at 8​:44 PM, Craig A. Berry <craig.a.berry@​gmail.com> wrote​:

It looks to me like $(MAKE) is a built-in variable and will expand to
whatever make you're actually running​:

Yes, it is make's equivalent of perl's $^X.

I misunderstood the issue; I assumed the problem was that the
top-level Makefile needed to pass the name of the make utility to
$Config{make}, and thought $(MAKE) would be a way to do this. Maybe
this is still the issue, and the value is hard-coded in some other
place. I've only searched kmx's gist for occurances of 'gmake', and
that was the only one I spotted; I haven't looked any deeper.

Cheers,
-Jan

[p5pRT]

From @kmx

On 18.12.2014 0​:14, Leon Timmermans via RT wrote​:

On Wed, Dec 17, 2014 at 4​:07 PM, kmx <kmx@​atlas.cz> wrote​:

Here is the first version -
https://gist.github.com/kmx/b5805847b6485c5c3a65
Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32
subdir.
It seems to work but definitely needs thorough testing.

Line 323 is wrong (should be a ifneq), other than that it looks good to me.

You are right, fixed.

https://gist.github.com/kmx/b5805847b6485c5c3a65#file-gnumakefile-L323

--
kmx