Should have sensible way for users/vendors to specify additional compile flags / override compiler from CLI

[kentfredric]

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

[Leont]

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.

I suspect the most obvious solution is to change make that additive instead of overwriting as it is now.

[dolmen]

Cc: @fperrad because you did (still do?) perl 5 cross-compilation

Just chiming in here. Was trying to put together a PR for image-size to get the build passing on Solaris (which has nothing to do with image-size fyi). Build.PL doesn't appear respect the the command line options are options passed into constructor. It seems to ignore this options and only look to Config.sh. The problem is for example on the Solaris build it's pointing to /usr/ucb/cc and so Compress::Zlib can not successfully be compiled without manual intervention.

Just chiming in here. Was trying to put together a PR for image-size to get the build passing on Solaris (which has nothing to do with image-size fyi). Build.PL doesn't appear to respect the the command line options are options passed into constructor per the documentation. It seems to ignore this options and only look to Config.sh. The problem is for example on the Solaris build it's pointing to /usr/ucb/cc and so Compress::Zlib can not successfully be compiled without manual intervention.