Skip Menu |

This queue is for tickets about the Glib CPAN distribution.

Report information
The Basics
Id: 17493
Status: resolved
Priority: 0/
Queue: Glib

People
Owner: kaffeetisch [...] gmx.de
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.103
Fixed in: (no value)



(Really broken in 1.104, but rt did not let me specify that value) When trying to build Glib on a FreeBSD system, I got the error: Writing Makefile for Glib "Makefile", line 1186: Missing dependency operator "Makefile", line 1188: Need an operator "Makefile", line 1190: Need an operator The lines in the Makefile are: ifeq ($(LINKTYPE), dynamic) BLIB_DONE=$(INST_DYNAMIC) else BLIB_DONE=$(INST_STATIC) endif and cannot be understand by a non-GNU make. In BSD make it should be something like .if ${LINKTYPE} == "dynamic" ... .else ... .endif But probably it's better to make the condition unnecessary at all. The installation works fine if I use gmake instead of the default make (but unfortunately this means I cannot install Glib out-of-the-box from the CPAN shell)
Subject: Possible fix
RT-Send-CC: scott [...] asofyet.org, rwmcfa1 [...] neces.com
Somebody submitted a patch for this to the sf.net tracker (which is down currently). I'm attaching it here again. It seems to fix the problem for me on FreeBSD 5.4 and doesn't seem to introduce new problems on Linux either. What do you guys think?
diff -cr rrr/Glib-1.102/MakeHelper.pm sss/Glib-1.102/MakeHelper.pm *** rrr/Glib-1.102/MakeHelper.pm Fri Feb 4 20:38:46 2005 --- sss/Glib-1.102/MakeHelper.pm Sun Jan 22 14:50:34 2006 *************** *** 373,405 **** # of blib. basically what we need to wait on is the static/dynamic # lib file to be created. the following trick is intended to handle # both of those cases without causing the other to happen. - my $blib_done; - # this is very sloppy, because different makes have different - # conditional syntaxes. - use Config; - if ($Config{make} eq 'nmake') { - warn "loathe nmake.\n"; - $blib_done = " - !If \"\$(LINKTYPE)\" == \"dynamic\" - BLIB_DONE=\$(INST_DYNAMIC) - !ELSE - BLIB_DONE=\$(INST_STATIC) - !ENDIF - "; - } else { - # assuming GNU Make - $blib_done = " - ifeq (\$(LINKTYPE), dynamic) - BLIB_DONE=\$(INST_DYNAMIC) - else - BLIB_DONE=\$(INST_STATIC) - endif - "; - } - " ! BLIB_DONE= ! $blib_done # documentation stuff build/doc.pl :: Makefile @xs_files --- 373,380 ---- # of blib. basically what we need to wait on is the static/dynamic # lib file to be created. the following trick is intended to handle # both of those cases without causing the other to happen. " ! BLIB_DONE= linkext # documentation stuff build/doc.pl :: Makefile @xs_files
While the patch makes it possible to use FreeBSD's make, it doesn't work when you use more than one job (make -j x). It dies with: make: don't know how to make blib/lib/Glib/GenPod.pm. Stop The BLIB_DONE hack was supposed to prevent this. So it looks like we still need that code. Can you provide a new patch that adds a new branch for FreeBSD's make? Or do you see a better way?
Subject: Re: [rt.cpan.org #17493]
Date: 13 Feb 2006 08:42:31 +0100
To: bug-Glib [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Torsten Schönfeld via RT" <bug-Glib@rt.cpan.org> writes: Show quoted text
> While the patch makes it possible to use FreeBSD's make, it doesn't work > when you use more than one job (make -j x). It dies with: > > make: don't know how to make blib/lib/Glib/GenPod.pm. Stop > > The BLIB_DONE hack was supposed to prevent this. So it looks like we > still need that code. Can you provide a new patch that adds a new > branch for FreeBSD's make? Or do you see a better way? >
It seems that dependencies are missing. Adding $(INST_LIB)/Glib/GenPod.pm $(INST_LIB)/Glib/ParseXSDoc.pm: pm_to_blib to the Makefile seems to help. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de BBBike - route planner for cyclists in Berlin WWW version: http://www.bbbike.de Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
Show quoted text
> It seems that dependencies are missing. Adding > > $(INST_LIB)/Glib/GenPod.pm $(INST_LIB)/Glib/ParseXSDoc.pm: pm_to_blib > > to the Makefile seems to help.
Yes, those dependencies do seem to help. But unfortunately, I just discovered that simply using BLIB_DONE=linkext as per the patch causes the docgen stage[1] to be run multiple times: once during normal building, and once when you issue "make install". Any ideas? [1] /usr/bin/perl -I blib/lib -I blib/arch -MGlib::GenPod -MGlib \ -e 'add_types ("doctypes"); ...'
Subject: Re: [rt.cpan.org #17493]
Date: 14 Feb 2006 23:33:23 +0100
To: bug-Glib [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Torsten Schönfeld via RT" <bug-Glib@rt.cpan.org> writes: Show quoted text
> > It seems that dependencies are missing. Adding > > > > $(INST_LIB)/Glib/GenPod.pm $(INST_LIB)/Glib/ParseXSDoc.pm: pm_to_blib > > > > to the Makefile seems to help.
> > Yes, those dependencies do seem to help. But unfortunately, I just > discovered that simply using BLIB_DONE=linkext as per the patch causes > the docgen stage[1] to be run multiple times: once during normal > building, and once when you issue "make install". > > Any ideas? >
A very rough idea: the problem seems a makefile construct like this: docgen: linkext touch docgen linkext: foo foo: touch foo If you say "make docgen", then the touch is done, every time, basically the same problem as in Glib's makefile. I succeeded in removing the problem by hacking the generated makefile: removing the PHONY-ness from the linkext and dynamic targets, and making linkext and dynamic "touch" files with the same names. But I doubt this is a nice solution. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de tknotes - A knotes clone, written in Perl/Tk. http://ptktools.sourceforge.net/#tknotes
It seems like nobody in the know is able to come up with a generic solution to this. So I think we should just add a FreeBSD-specific branch to the BLIB_DONE thing. Slaven, what's the best way to find out whether FreeBSD's own make is used? Does $Config{make} contain anything useful? perl -le'use Config; print $Config{make};'
Subject: Re: [rt.cpan.org #17493] Makefile doesn't work with FreeBSD's make
Date: 16 Apr 2006 22:24:05 +0200
To: bug-Glib [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Torsten Schönfeld via RT" <bug-Glib@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=17493 > > > It seems like nobody in the know is able to come up with a generic > solution to this. So I think we should just add a FreeBSD-specific > branch to the BLIB_DONE thing. Slaven, what's the best way to find out > whether FreeBSD's own make is used? Does $Config{make} contain anything > useful? > > perl -le'use Config; print $Config{make};' >
This returns "make". GNU make is spelled "gmake" on BSD systems. Well, nobody can stop a BSD user from using gmake instead of make for compiling perl modules, and I don't know of a way to determine whether BSD make or GNU make is actually used. BTW, I assume this is not a FreeBSD-only problem, but openbsd and netbsd have the same problem. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de tkruler - Perl/Tk program for measuring screen distances http://ptktools.sourceforge.net/#tkruler
On Sun Apr 16 17:42:38 2006, slaven@rezic.de wrote: Show quoted text
> "Torsten Schönfeld via RT" <bug-Glib@rt.cpan.org> writes: >
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=17493 > > > > > It seems like nobody in the know is able to come up with a generic > > solution to this. So I think we should just add a FreeBSD-specific > > branch to the BLIB_DONE thing. Slaven, what's the best way to find out > > whether FreeBSD's own make is used? Does $Config{make} contain anything > > useful? > > > > perl -le'use Config; print $Config{make};' > >
> > This returns "make". GNU make is spelled "gmake" on BSD systems. Well, > nobody can stop a BSD user from using gmake instead of make for > compiling perl modules, and I don't know of a way to determine whether > BSD make or GNU make is actually used. > > BTW, I assume this is not a FreeBSD-only problem, but openbsd and > netbsd have the same problem. >
Please see the attached patch to workaround the problem on BSD systems. The patch now introduces a third variant for the if-section in the generated Makefile. FYI, the only possibility to distinguish between BSD make and GNU make seems to be the name of the Makefile. GNU make chooses first GNUmakefile, then Makefile etc. BSD make (at least the version which comes with FreeBSD 6.1) first chooses BSDmakefile, then Makefile etc. With this knowledge one could create another way to solve the problem: just dump generate BSDmakefile and GNUmakefile and let the make tool decide which file to use. Regards, Slaven
# # # To apply this patch: # STEP 1: Chdir to the source directory. # STEP 2: Run the 'applypatch' program with this patch file as input. # # If you do not have 'applypatch', it is part of the 'makepatch' package # that you can fetch from the Comprehensive Perl Archive Network: # http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz # In the above URL, 'x' should be 2 or higher. # # To apply this patch without the use of 'applypatch': # STEP 1: Chdir to the source directory. # STEP 2: Run the 'patch' program with this file as input. # #### End of Preamble #### #### Patch data follows #### diff -up 'build/Glib-1.142-8XPuil/MakeHelper.pm' 'new.build/Glib-1.142-8XPuil/MakeHelper.pm' Index: ./MakeHelper.pm Prereq: 1.36 --- ./MakeHelper.pm Tue Oct 17 21:56:32 2006 +++ ./MakeHelper.pm Tue Jan 23 21:36:29 2007 @@ -385,6 +385,14 @@ BLIB_DONE=\$(INST_DYNAMIC) BLIB_DONE=\$(INST_STATIC) !ENDIF "; + } elsif ($^O =~ m{^(freebsd|netbsd|openbsd)$}i) { + $blib_done = " +.if \$(LINKTYPE) == dynamic +BLIB_DONE=\$(INST_DYNAMIC) +.else +BLIB_DONE=\$(INST_STATIC) +.endif +"; } else { # assuming GNU Make $blib_done = " #### End of Patch data #### #### ApplyPatch data follows #### # Data version : 1.0 # Date generated : Tue Jan 23 21:38:28 2007 # Generated by : makepatch 2.03 # Recurse directories : Yes # Excluded files : (\A|/).*\~\Z # (\A|/).*\.a\Z # (\A|/).*\.bak\Z # (\A|/).*\.BAK\Z # (\A|/).*\.elc\Z # (\A|/).*\.exe\Z # (\A|/).*\.gz\Z # (\A|/).*\.ln\Z # (\A|/).*\.o\Z # (\A|/).*\.obj\Z # (\A|/).*\.olb\Z # (\A|/).*\.old\Z # (\A|/).*\.orig\Z # (\A|/).*\.rej\Z # (\A|/).*\.so\Z # (\A|/).*\.Z\Z # (\A|/)\.del\-.*\Z # (\A|/)\.make\.state\Z # (\A|/)\.nse_depinfo\Z # (\A|/)core\Z # (\A|/)tags\Z # (\A|/)TAGS\Z # p 'MakeHelper.pm' 15517 1169584589 0100644 #### End of ApplyPatch data #### #### End of Patch kit [created: Tue Jan 23 21:38:28 2007] #### #### Patch checksum: 54 1785 41951 #### #### Checksum: 72 2409 27949 ####
Show quoted text
> Please see the attached patch to workaround the problem on BSD systems. > The patch now introduces a third variant for the if-section in the > generated Makefile.
Thanks! With this, what happens if someone uses gmake on one of those BSDs? Show quoted text
> FYI, the only possibility to distinguish between BSD make and GNU make > seems to be the name of the Makefile. GNU make chooses first > GNUmakefile, then Makefile etc. BSD make (at least the version which > comes with FreeBSD 6.1) first chooses BSDmakefile, then Makefile etc. > With this knowledge one could create another way to solve the problem: > just dump generate BSDmakefile and GNUmakefile and let the make tool > decide which file to use.
Hmm, that sounds circuitous. I can't help thinking that there got to be a better way to solve this issue.
CC: SREZIC [...] cpan.org
Subject: Re: [rt.cpan.org #17493] Makefile doesn't work with FreeBSD's make
Date: 25 Jan 2007 23:16:43 +0100
To: bug-Glib [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Torsten Schönfeld via RT" <bug-Glib@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=17493 > >
> > Please see the attached patch to workaround the problem on BSD systems. > > The patch now introduces a third variant for the if-section in the > > generated Makefile.
> > Thanks! With this, what happens if someone uses gmake on one of > those BSDs?
Ka boom! Typically BSD users will use BSD make. It's the default when auto-configuring CPAN.pm, it is documented in most READMEs/INSTALLs of perl modules to use "make; make test; make install". GNU make is installed as "gmake" on BSD machines if it is done through a port or package. Show quoted text
>
> > FYI, the only possibility to distinguish between BSD make and GNU make > > seems to be the name of the Makefile. GNU make chooses first > > GNUmakefile, then Makefile etc. BSD make (at least the version which > > comes with FreeBSD 6.1) first chooses BSDmakefile, then Makefile etc. > > With this knowledge one could create another way to solve the problem: > > just dump generate BSDmakefile and GNUmakefile and let the make tool > > decide which file to use.
> > Hmm, that sounds circuitous. I can't help thinking that there got to be > a better way to solve this issue.
Unfortunately, it seems the case if one really needs the conditions or other extended make stuff. I found no way of determining within a Makefile whether BSD make or GNU make is the caller. And I would be really happy to know if there is a way. Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de tktimex - time recording tool http://sourceforge.net/projects/ptktools/
RT-Send-CC: scott [...] asofyet.org
On Fri Jan 26 02:39:53 2007, slaven@rezic.de wrote: Show quoted text
> > Thanks! With this, what happens if someone uses gmake on one of > > those BSDs?
> > Ka boom! Typically BSD users will use BSD make. It's the default when > auto-configuring CPAN.pm, it is documented in most READMEs/INSTALLs of > perl modules to use "make; make test; make install". GNU make is > installed as "gmake" on BSD machines if it is done through a port or > package.
OK, so here's an update to your patch that checks the environment variable FORCE_GMAKE on BSDs to decide. If it's set to something true, gmake syntax is used. Does that make sense? Is FORCE_GMAKE a good name, or is there some kind of standard name that's usually used for this?
RT-Send-CC: scott [...] asofyet.org
On Sat Feb 10 07:43:16 2007, TSCH wrote: Show quoted text
> OK, so here's an update to your patch that checks the environment > variable FORCE_GMAKE on BSDs to decide. If it's set to something true, > gmake syntax is used.
*Here* it is.
Index: MakeHelper.pm =================================================================== RCS file: /cvsroot/gtk2-perl/gtk2-perl-xs/Glib/MakeHelper.pm,v retrieving revision 1.36 diff -u -d -p -r1.36 MakeHelper.pm --- MakeHelper.pm 14 Jul 2006 18:43:45 -0000 1.36 +++ MakeHelper.pm 10 Feb 2007 12:31:14 -0000 @@ -374,8 +374,12 @@ sub postamble_docs_full { # lib file to be created. the following trick is intended to handle # both of those cases without causing the other to happen. my $blib_done; + # this is very sloppy, because different makes have different - # conditional syntaxes. + # conditional syntaxes. we support three brands: nmake, BSD make, and + # GNU make. On Windows, we use nmake. On BSD we use BSD make unless + # the environment variable FORCE_GMAKE is set, in which case we use + # gmake. Everywhere else, we use gmake. require Config; if ($Config::Config{make} eq 'nmake') { $blib_done = " @@ -385,6 +389,14 @@ BLIB_DONE=\$(INST_DYNAMIC) BLIB_DONE=\$(INST_STATIC) !ENDIF "; + } elsif ($^O =~ m{^(freebsd|netbsd|openbsd)$}i && !$ENV{FORCE_GMAKE}) { + $blib_done = " +.if \$(LINKTYPE) == dynamic +BLIB_DONE=\$(INST_DYNAMIC) +.else +BLIB_DONE=\$(INST_STATIC) +.endif +"; } else { # assuming GNU Make $blib_done = "
Show quoted text
> OK, so here's an update to your patch that checks the environment > variable FORCE_GMAKE on BSDs to decide. If it's set to something true, > gmake syntax is used.
Committed to both branches.