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.
|
