-
Notifications
You must be signed in to change notification settings - Fork 37
Description
It is somewhat desirable for vendors and users alike to have a straightforward way of specifying overrides for executables, and supplementary flags to append to compilation ( such as cflags and ldflags ) which don't also conflict with those provided by perl itself, or conflict with those provided by the distribution itself.
The closest one presently gets is specifying --extra-compiler-flags and --extra-linker-flags on the commandline, but they can be impacted by the Build.PL itself.
Presently most the options a consumer has at their disposal either risks over-riding a sensible default just to extend it, or having their extension simply ignored.
This request is for something closer to what people experience in C land, where if a consumer specifies CFLAGS and LDFLAGS in their environment, the toolchain will tak those in at the right place without simply losing all existing configuration.
IRC Backstory:
06:58:01 <@kentnl> EUMM and MB Question: If a module is using this, https://metacpan.org/pod/ExtUtils::CppGuess # are there ways to override those guesses at the EUMM/MB level? ( ie: via ENV
or invocations at install side ) or would that require patches to CppGuess to support such adjustment
06:58:16 <+dipsy> [ ExtUtils::CppGuess - guess C++ compiler and flags - metacpan.org ]
06:58:53 <@leont> Probably the latter
07:00:13 <@kentnl> it returns data to MB in the form of "extra_compiler|linker_flags"... but I have no idea what "extra" means here =)
07:03:01 <@leont> Those are really argument to ExtUtils::CBuilder
07:18:34 <@kentnl> leont: so if somebody did perl Build.PL --config "optimize= ... " --config "lddlflags=... " in the presence of CppGuess, would they get completely ignored?
07:19:22 <@leont> That should work
07:19:33 <@leont> But overriding lddlflags is something I'd recommend against
07:21:06 <@leont> It tends to contain important stuff
07:37:09 <@kentnl> So, imagine theres a XS based dist your code uses a lot of, and you want to squeeze out a few extra cycles by doing a profile-guided compile. This requires adding
-fprofile-generate to both cflags and ldflags. How would you go about doing that without a) editing the .PL file by hand, or b) rebuilding perl itself ( or C) doing nasty
shit with editing $Config ) ).
07:37:52 <@kentnl> ( Also, I tried doing this with perl itself earlier in the week just for kicks, couldn't get it to build because it failed its own tests in ExtUtils::Constant for some
reason I haven't dug into yet )
07:43:18 <@leont> In MB, --extra-compiler-flags and --extra-linker-flags would be the easiest way
07:44:12 <@kentnl> So I'm guessing the CppGuess just clobbers those parts eh.
07:45:38 <@leont> Kind of
07:46:06 <@leont> For MM it's also taking the obvious approach, but OTHERLDFLAGS is even harder to set from the outside
07:52:36 <@kentnl> so optimise= # is this extending or obliterrating the defaults?
07:54:41 <@leont> obliterrating, but at least in that field I wouldn't expect anything essential
07:54:56 <@leont> It's only passed on to the compilation stage, though
08:06:32 <@kentnl> so the overall vibe I get is "if you want to stick stuff in after dist-specified flags, there's presently no way of getting that to happen" ( as oppossed to "what you're
trying to do is too crazy and should never be done" )
08:07:10 * kentnl knows its a little crazy in the "probably viable but you get to keep the pieces" kind but thats acceptable for this context IME =)
08:13:08 <@leont> This is harder than it should be, yet
08:13:10 <@leont> yes
08:13:31 <@leont> It's also perfectly reasonable to want this, IMO
Motivation:
bgo #261375: dev-lang/perl and xs: bad CFLAGS and LDFLAGS handling
list of gentoo bugs pertaining to perl modules ignoring user specified flags
bgo # 233354: LDFLAGS used for Module-Build packages are LDFLAGS from dev-lang/perl