Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PATCH] Time-HiRes: Fix generating Makefile when it does not exist #16533

Open
p5pRT opened this issue Apr 25, 2018 · 9 comments
Open

[PATCH] Time-HiRes: Fix generating Makefile when it does not exist #16533

p5pRT opened this issue Apr 25, 2018 · 9 comments

Comments

@p5pRT
Copy link

p5pRT commented Apr 25, 2018

Migrated from rt.perl.org#133153 (status was 'open')

Searchable as RT133153$

@p5pRT
Copy link
Author

p5pRT commented Apr 25, 2018

From @pali

More times when compiling/updating perl codebase I'm getting following
compile error​:

./miniperl -Ilib make_ext.pl lib/auto/Time/HiRes/HiRes.so MAKE="make" LIBPERL_A=libperl.a LINKTYPE=dynamic
Makefile.PL​: The "xdefine" exists, skipping the configure step.
Use "/home/pali/perl/miniperl Makefile.PL --configure"
or​: "/home/pali/perl/miniperl Makefile.PL --force
to force the configure step.
Warning​: No Makefile!
make[1]​: Entering directory '/home/pali/perl/dist/Time-HiRes'
make[1]​: *** No rule to make target 'all'. Stop.
make[1]​: Leaving directory '/home/pali/perl/dist/Time-HiRes'
make[1]​: Entering directory '/home/pali/perl/dist/Time-HiRes'
make[1]​: *** No rule to make target 'all'. Stop.
make[1]​: Leaving directory '/home/pali/perl/dist/Time-HiRes'
Unsuccessful make(dist/Time-HiRes)​: code=512 at make_ext.pl line 570.
makefile​:582​: recipe for target 'lib/auto/Time/HiRes/HiRes.so' failed
make​: *** [lib/auto/Time/HiRes/HiRes.so] Error 2

Reason is that Makfile.PL does not generate Makefile if --configure or
--force is not specified. And it does not generate it even when Makefile
does not exist.

It is really ridiculous that Makefile.PL does not generate Makefile without
specifying some non-standard flags which even make_ext.pl does not support.

This patch ensures that Makefile is always generated when Makefile.PL is
called despite which arguments were passed. So it fixes above problem with
compilation.

@p5pRT
Copy link
Author

p5pRT commented Apr 25, 2018

From @pali

0001-Time-HiRes-Fix-generating-Makefile-when-does-not-exi.patch
From 1cbf6f0d9e6e3f60774bdc01635c1dc63600ebcb Mon Sep 17 00:00:00 2001
From: Pali <pali@cpan.org>
Date: Wed, 25 Apr 2018 13:19:42 +0200
Subject: [PATCH] Time-HiRes: Fix generating Makefile when it does not exist

More times when compiling/updating perl codebase I'm getting following
compile error:

./miniperl -Ilib make_ext.pl lib/auto/Time/HiRes/HiRes.so  MAKE="make" LIBPERL_A=libperl.a LINKTYPE=dynamic
Makefile.PL: The "xdefine" exists, skipping the configure step.
Use "/home/pali/perl/miniperl Makefile.PL --configure"
or: "/home/pali/perl/miniperl Makefile.PL --force
to force the configure step.
Warning: No Makefile!
make[1]: Entering directory '/home/pali/perl/dist/Time-HiRes'
make[1]: *** No rule to make target 'all'.  Stop.
make[1]: Leaving directory '/home/pali/perl/dist/Time-HiRes'
make[1]: Entering directory '/home/pali/perl/dist/Time-HiRes'
make[1]: *** No rule to make target 'all'.  Stop.
make[1]: Leaving directory '/home/pali/perl/dist/Time-HiRes'
Unsuccessful make(dist/Time-HiRes): code=512 at make_ext.pl line 570.
makefile:582: recipe for target 'lib/auto/Time/HiRes/HiRes.so' failed
make: *** [lib/auto/Time/HiRes/HiRes.so] Error 2

Reason is that Makfile.PL does not generate Makefile if --configure or
--force is not specified. And it does not generate it even when Makefile
does not exist.

It is really ridiculous that Makefile.PL does not generate Makefile without
specifying some non-standard flags which even make_ext.pl does not support.

This patch ensures that Makefile is always generated when Makefile.PL is
called despite which arguments were passed. So it fixes above problem with
compilation.
---
 dist/Time-HiRes/Makefile.PL | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dist/Time-HiRes/Makefile.PL b/dist/Time-HiRes/Makefile.PL
index e0f7dd9a2f..bab8276929 100644
--- a/dist/Time-HiRes/Makefile.PL
+++ b/dist/Time-HiRes/Makefile.PL
@@ -1068,9 +1068,9 @@ sub main {
 	} else {
 	    init();
 	}
-	doMakefile;
-	doConstants;
     }
+    doMakefile;
+    doConstants;
     my $make = $Config{'make'} || "make";
     unless (exists $ENV{PERL_CORE} && $ENV{PERL_CORE}) {
 	print  <<EOM;
-- 
2.11.0

@p5pRT
Copy link
Author

p5pRT commented Apr 25, 2018

From csjewell@cpan.org

On Wed, 25 Apr 2018 04​:30​:36 -0700, pali@​cpan.org wrote​:

More times when compiling/updating perl codebase I'm getting following
compile error​:

./miniperl -Ilib make_ext.pl lib/auto/Time/HiRes/HiRes.so MAKE="make"
LIBPERL_A=libperl.a LINKTYPE=dynamic
Makefile.PL​: The "xdefine" exists, skipping the configure step.

The patch is not the correct way to fix the problem - it only symptom-fixes, it does not fix the cause of the problem. The cause is that the "xdefine" file still exists between builds. I would ask why a 'make realclean' or 'make clean' (whatever you are doing between builds that prepares it for rebuilding) is not removing the "xdefine" file (which is the flag that says 'I configured already'), instead.

@p5pRT
Copy link
Author

p5pRT commented Apr 25, 2018

From [Unknown Contact. See original ticket]

On Wed, 25 Apr 2018 04​:30​:36 -0700, pali@​cpan.org wrote​:

More times when compiling/updating perl codebase I'm getting following
compile error​:

./miniperl -Ilib make_ext.pl lib/auto/Time/HiRes/HiRes.so MAKE="make"
LIBPERL_A=libperl.a LINKTYPE=dynamic
Makefile.PL​: The "xdefine" exists, skipping the configure step.

The patch is not the correct way to fix the problem - it only symptom-fixes, it does not fix the cause of the problem. The cause is that the "xdefine" file still exists between builds. I would ask why a 'make realclean' or 'make clean' (whatever you are doing between builds that prepares it for rebuilding) is not removing the "xdefine" file (which is the flag that says 'I configured already'), instead.

@p5pRT
Copy link
Author

p5pRT commented Apr 26, 2018

From @bulk88

On Wed, 25 Apr 2018 09​:17​:47 -0700, csjewell@​cpan.org wrote​:

The patch is not the correct way to fix the problem - it only symptom-
fixes, it does not fix the cause of the problem. The cause is that the
"xdefine" file still exists between builds. I would ask why a 'make
realclean' or 'make clean' (whatever you are doing between builds that
prepares it for rebuilding) is not removing the "xdefine" file (which
is the flag that says 'I configured already'), instead.

I agree, why is there a build product on disk in the first place? .gitignore problem or makefile clean target problem?

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Apr 26, 2018

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

@p5pRT
Copy link
Author

p5pRT commented Apr 26, 2018

From @pali

make_ext.pl in more cases remove Makefile file and then expect that
calling Makefile.PL without any additional argument would generate it
again. This is working fine for all subparts except Time-HiRes which
does not generate Makefile again.

If you think that it is incorrect, then (re)define Makefile.PL API under
which conditions is Makefile being generated and fix scripts around
which calls Makefile.

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2019

From @tonycoz

On Thu, 26 Apr 2018 07​:12​:31 -0700, pali@​cpan.org wrote​:

make_ext.pl in more cases remove Makefile file and then expect that
calling Makefile.PL without any additional argument would generate it
again. This is working fine for all subparts except Time-HiRes which
does not generate Makefile again.

If you think that it is incorrect, then (re)define Makefile.PL API under
which conditions is Makefile being generated and fix scripts around
which calls Makefile.

I think the correct behaviour here would be to always probe, rather than making it conditional on xdefine being missing.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jan 24, 2019

From @pali

On Tuesday 22 January 2019 19​:44​:02 Tony Cook via RT wrote​:

I think the correct behaviour here would be to always probe, rather than making it conditional on xdefine being missing.

This should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants