cpan, MakeMaker, CFLAGS (and CCFLAGS)

[Andrew]

Hi, all

does anyone know how to control the CFLAGS in cpan, the script?

I have explicitly set my system environment CFLAGS (for my pentiumIII
system).

when i install modules w/cpan, cpan ignores my CFLAGS and imposes
"...march=i386 -mtune=pentium4 .."

for my life i can't figure out where this is coming from. I've looked
in MakeMaker source (seeing "CCFLAGS", i defined that, too), "man
cpan", etc., to no avail.

I don't want to have to change one or a dozen Makefile's with every
installation. I need to change the default in cpan and anything else
related to MakeMaker. Any ideas?

tia
andrew

 

[Sherm Pendley]

when i install modules w/cpan, cpan ignores my CFLAGS and imposes
"...march=i386 -mtune=pentium4 .."

for my life i can't figure out where this is coming from.

It's coming from Perl, because that's what perl was built with.

Have a look at Perl's core Config.pm. But, be careful - you can make
changes there that result in unbuildable and/or unusable modules. Make
a backup first, and make one change at a time, testing each one.

sherm--

 

[Andrew]

It's coming from Perl, because that's what perl was built with.

Have a look at Perl's core Config.pm. But, be careful - you can make
changes there that result in unbuildable and/or unusable modules. Make
a backup first, and make one change at a time, testing each one.

You mean, a backup of "Config.pm"?

And if I were to rebuild perl per se, would that cause any
incompatibilities? If so, which ones, and what is the workaround?
Rebuild all the additional modules I installed with cpan? (If, so, i
guess i'd have to go through my cpan cache/build and rebuild and
reinstall "by hand" everything? unless there's an easier way...)

thanks!

andrew

 

[Sherm Pendley]

You mean, a backup of "Config.pm"?

Yes. If you want to undo any change(s) you've made to Config.pm, how useful
do you imagine it might be to have a backup of some other file? ;-)

And if I were to rebuild perl per se

I didn't say anything about rebuilding Perl...

sherm--

 

[Andrew]

for my life i can't figure out where this is coming from.

Yes. If you want to undo any change(s) you've made to Config.pm, how useful
do you imagine it might be to have a backup of some other file? ;-)


I didn't say anything about rebuilding Perl...

I didn't mean to suggest that you did. Perhaps I jumbled too many
distinct things into one sentence. What I meant was:

And what if I rebuilt the perl interpreter? Would that avoid the
dangers you caution me about?

Next, if rebuilding Perl /is/ a sure solution, I'd have to rebuild the
"extra" modules, too, right? Or else there would be
incompatibilities(?)

andrew

 

[Sherm Pendley]

And what if I rebuilt the perl interpreter? Would that avoid the
dangers you caution me about?

Well, yes, but it's absurd overkill for what you want to accomplish.

The dangers I'm talking about are things like accidentally deleting an
important option, such as "-lperl", which would result in modules not
building at all.

At any rate, I *highly* doubt that there's much to be gained by changing
the flags you mentioned: "-march=i386 -mtune=pentium4". Perl modules that
have C code are generally just very thin wrappers around external libraries,
and won't benefit much (if at all) from processor-specific tuning options
like that.

What exactly is it you're trying to accomplish by changing those flags,
anyway? If you're trying to speed things up, you're usually better off
looking at algorithmic improvements, not compiler options.

sherm--

 

[Andrew]

Well, yes, but it's absurd overkill for what you want to accomplish.

Perhaps. Unless the affected code is heavily used, and you're due for a
perl upgrade anyway, and you don't have to do much _beyond_ compiling
perl (and perhaps recompiling the additional modules).

The dangers I'm talking about are things like accidentally deleting an
important option, such as "-lperl", which would result in modules not
building at all.
thanks.


At any rate, I *highly* doubt that there's much to be gained by changing
the flags you mentioned: "-march=i386 -mtune=pentium4". Perl modules that
have C code are generally just very thin wrappers around external libraries,
and won't benefit much (if at all) from processor-specific tuning options
like that.

What exactly is it you're trying to accomplish by changing those flags,
anyway? If you're trying to speed things up, you're usually better off
looking at algorithmic improvements, not compiler options.

Bingo! All that you've just said is relevant and to the point, filling
in the right gaps in my knowledge. Yes, the fact that I'm probably
dealing with thin C wrappers would remove the concern altogether. I
wasn't sure if there was something in P4-optimized code that could
choke/stall the P3 processor -- seems like i read this somewhere... or
maybe that depends on a particular optimization _level_ (i.e., -O2,
-O3, etc.)

andrew

 

[Sherm Pendley]

Bingo! All that you've just said is relevant and to the point

Thanks. It's a struggle at times... I have a tendency to digress. ;-)

in the right gaps in my knowledge. Yes, the fact that I'm probably
dealing with thin C wrappers would remove the concern altogether.

You could still apply better tuning options to the wrapped libraries.

sherm--

 

[brian d foy]

Hi, all

does anyone know how to control the CFLAGS in cpan, the script?

The cpan script simply wraps CPAN.pm. If your CPAN.pm respects your
CFLAGS setting, cpan(1) should too. If that's not the case, please
let me know.