Dynamic PMC building - include and libpath options?
Jonathan Worthington
Tonight I've been working to get BCG to compile, link and pass its
tests on Windows. It does, but I also spotted that the include path
for BCG has been hard coded into the dynamic PMC build script, which
is a Bad Thing. I had to do a similar-ish (but less obviously evil
looking) thing to specify a library path to get things working on Win32.
I propose that build/tools/dynpmc.pl can take:
* -I to specify include path(s) on the compile phase
* -L to specify library path(s) on the link phase
So we can factor those specifics out of there.
Anyone against? If not, will do it later this week.
Thanks,
Jonathan
Leopold Toetsch
most[1] of ...
> build/tools/dynpmc.pl
... should go away in favor of standard Makefile rules
my 2c
leo
[1] except generation of *_group for bundled PMCs.
Leopold Toetsch
> most[1] of ...
>
> > build/tools/dynpmc.pl
>
> ... should go away in favor of standard Makefile rules
That answer was probably a bit too terse. Here are my thoughts:
1) perl Configure.pl creates all the settings to properly compile and link
(shared or dynamic) parrot or libs.
2) Makefiles can use makefile variables or substitutions provided by
config/gen/makefiles.pm or even posix substitutions.
3) Perl programs have all the config variables available with:
use qw(lib); # or similar paths
use Parrot::Config qw/%PConfig/;
4) Parrot's providing access to all these config vars too: see e.g.
t/pmc/config.t or tools/dev/src-t.sh
5) lib/Parrot/Test.pm needs this info too, to run t/src tests
6) and dynpmcs, dynops, ... other stuff not even in the tree ...
7) if something is missing or wrong with 1) it should be adjusted/fixed there
and not ever and ever again in 2) - 6).
leo