Bug #11616 for ExtUtils-MakeMaker: processPL() uses "::" which breaks dmake

Tue Feb 22 06:48:45 2005 shay [...] cpan.org - Ticket created

Subject:

processPL() uses "::" which breaks dmake

The attached Foo module does not build on Win32 using dmake (either Sarathy's 4.1 build, or my new 4.3 build). It works fine with VC++ / nmake. The problem is that bar.c and bar.o do not get made, and hence we get a link error complaining that bar.o is missing. Issuing "dmake bar.c" before "dmake" works fine. It seems to get confused over how to make bar.c when left to its own devices. Here's the section from the Makefile for making bar.c: bar.c :: bar.c.PL pm_to_blib.ts $(PERLRUNINST) bar.c.PL Note the "::", which is normally used when there is another bar.c target in the Makefile. In this case there actually isn't another bar.c target, and changing "::" to ":" fixes it. The Makefile.PL contains a commented-out processPL() to do this, and it works fine for me. I think this is a dmake bug really, but if it is OK for processPL() to always emit a single ":" then it would be better for EU::MM to be changed to do so for users of existing dmake's. Failing that, can EU::MM determine when a "::" would be *needed* and only use it where it is really needed? If not, then the final cop-out is just to wait for a dmake fix. I've logged the bug on the OpenOffice.org website: http://www.openoffice.org/issues/show_bug.cgi?id=43310

Download Foo-0.01.tar.gz
application/x-gzip 663b

Message body not shown because it is not plain text.

Sat Mar 12 13:25:23 2005 mschwern [...] cpan.org - Correspondence added

[SHAY - Tue Feb 22 06:48:45 2005]: Show quoted text

> Note the "::", which is normally used when there is another bar.c > target in the Makefile. In this case there actually isn't another > bar.c target, and changing "::" to ":" fixes it. The Makefile.PL > contains a commented-out processPL() to do this, and it works fine > for me. > > I think this is a dmake bug really, but if it is OK for processPL() to > always emit a single ":" then it would be better for EU::MM to be > changed to do so for users of existing dmake's. Failing that, can > EU::MM determine when a "::" would be *needed* and only use it > where it is really needed?

I checked back through the change history and MakeMaker's always worked this way so I'm disinclined to touch it just now. I'll come back to it after I can get a stable release out the door.

Sat Mar 12 13:25:24 2005 mschwern [...] cpan.org - Status changed from 'new' to 'open'

Tue Jun 07 04:20:48 2005 shay [...] cpan.org - Correspondence added

[SHAY - Tue Feb 22 06:48:45 2005]: Show quoted text

> I think this is a dmake bug really, but if it is OK for processPL() to > always emit a single ":" then it would be better for EU::MM to be > changed to do so for users of existing dmake's. Failing that, can > EU::MM determine when a "::" would be *needed* and only use it > where it is really needed? If not, then the final cop-out is just > to wait for a dmake fix. I've logged the bug on the OpenOffice.org > website: > > http://www.openoffice.org/issues/show_bug.cgi?id=43310

The dmake bug has now been fixed in the 4.4-cvs version, and I've released a new binary build of that version as "dmake-4.4-20050606-SHAY". The sample module now works OK using the new dmake without the processPL() hack :)

Tue Jul 16 08:45:35 2013 BINGOS [...] cpan.org - Correspondence added 5 min

It's been 8 years, I'll mark this as resolved. Many thanks.

Tue Jul 16 08:45:36 2013 BINGOS [...] cpan.org - Status changed from 'open' to 'resolved'