[Module-build-general] Perl Compiler Collection

[Randy W. S. <Ra...@Th...>]

On 2/26/2003 10:04 AM, Ken Williams wrote:
 >
 > On Tuesday, February 25, 2003, at 06:53  PM, Randy W. Sims wrote:
 >
 >> On 2/24/2003 12:56 PM, Ken Williams wrote:
 >>
 >>> That can wait until the future.  To do this cleanly, I think we could
 >>> create a module like ExtUtils::C with classes like
 >>> ExtUtils::C::Compiler and ExtUtils::C::Linker that Module::Build
 >>> could just use transparently.  Its purpose would be to compile and
 >>> link things that will be linked in with Perl modules (not a general
 >>> tool for arbitrary C code), using the same interface regardless of
 >>> platform.
 >>> We could use that module in other situations too, like in the testing
 >>> code for ExtUtils::ParseXS.
 >>> Probably the code you've written for Win32 and the code I wrote for
 >>> Unix would be a good start toward such a module.  But given that the
 >>> module doesn't exist yet, we'll just have to wait. =)
 >>
 >>
 >> I've been thinking very seriously about writing those modules. My
 >> problem is the more I think about it the more ambitious the design
 >> becomes. I'm more inclined at the moment to design them as a framework
 >> not limited to 'C' and 'XS', so that Inline::* modules could make use
 >> of the framework if desired. Instead of ExtUtils::C::Linker, there
 >> would be something like:
 >>
 >> my $cc = new ExtUtils::Compiler(
 >>   LANG  => 'C',
 >>   FLAGS => ...
 >> );
 >>
 >> $cc->compile( source => 'source.c', output => 'source.o' );
 >>
 >> In other words, it would operate like 'gcc' does, where it is a
 >> front-end driver for any number of different compilers.
 >
 >
 > Eek, dangerous road! ;-)  When I've entertained writing this, it's only
 > by limiting the scope of the design that I can convince myself it's
 > worth doing, because I might have a reasonable chance of ever 
finishing. =)
 >
 > That said, probably all you'd need to do is define the *interfaces*,
 > implement the stuff we need for C compilation, and let other people
 > provide the code to support various languages.


I've been playing catch-up for the last few days...

(If you or anyone one you know uses any of those legal pep-pills with 
Ephedrine, STOP. I've abused those pill for a few years now, trying to 
sqeeze more time out of each day, but I ended up going to the hospital 
the Sunday before last because my blood-pressure went thru the roof. For 
about a week I was back-and-forth between doctor and hospital for tests 
because of those stupid pills. Needless to say, I will be taking no more 
of those (not to mention the gallons of coffee I drink each week)--Thiry 
is much too young for that kind of drama. --END OF PUBLIC SAFETY MESSAGE :)

Anyway. If you still think it would be a good idea to develop these 
modules, I think I'll get started on them (finally!) this weekend. I 
would like to work with you to make sure that what I come up with will 
be appropriate for M::B.

I do plan to limit the initial scope to XS/C/C++ as that is all that is 
required for perl extensions (that I've encountered), but I also want to 
try to keep it open ended where feasible so it can be extended later.

I have more than a few pages of notes I've jotted down over the past 
month or so that I need to put together for my initial spec., but here 
are some of the main points of what I propose:

The modules will be in the namespace ExtUtils::PCC (Perl Compiler 
Collection). I'm open to better name suggestions.

The main modules will be Compiler, Linker, Archiver (???), and Shell. 
The latter will be used by the others for shell quoting, finding 
executables, and invoking the respective tool, etc.

Each of the main modules will have subclasses based on the name of the 
compiler/linker. I'm not sure if there is any need for anything platform 
specific here; If so maybe I can have the main class try looking for a 
an appropriate class by generating several permutations on tool name, 
tool version, and platform--going from most specific to most general. 
For example it might first look for a module gcc_3*_linux, if not found 
then gcc_3* and finally gcc. Or, something like that; implementation 
often diverges from the initial idealization.

Primary responsibilities of these modules would include 
compiling/linking dynamic extensions, static extensions, and 
compiling/linking dependent libraries (ex. Compiler::Zlib). Optionally 
future versions could allow querying capabilities/information about the 
tool (Ex. invoking gcc --version to return the exact version, etc).

When constructing the object the user can specify whether or not an 
extension is being built (as opposed to a support lib). If it is an 
extension then the various flags and defines specified in Config.pm will 
be included in the commands as appropriate.

Default construction will use the compiler/linker/shell etc. specified 
in Config.pm unless overriden by user.

Each of Compiler/Linker/Archiver will specify generic option names that 
can be used to set options that are common (i.e. generate debugging 
info, set optimization level, set output file name, etc).

Each class will keep track of files that are generated.

Any ideas, suggestions, criticism are welcome. I don't /think/ it would 
take very long to get an initial implementation working that abstracted 
away what is done in M::B & EU::MakeMaker.

Randy.