Hi listers,
> > I'm not quite sure, if we need the additional complexity of a
> > build-script that generates parrot-config. It's for sure more flexible
> > but OTOH we probably just need a few shortcuts, which could be handled
> > directly too.
Ok two comments about the complexity of a build script.
(1) I would argue that the build-script adds a fairly small amount of
complexity. The build script itself is relatively short and most of the
original parrot-config is just HERE-DOC'ed into the script. It is
especially un-complex if one considers that one can remove the old
build step that constructed config.fpmc. Since (new) parrot-config.pbc
is constructed at the same time (old) config.fpmc was constructed:
everybody down stream from the creation of parrot-config could rely on
it and config.fpmc could be removed entirely. In this light, the build
script could maybe be seen to reduce the complexity (by localizing the
building and utilization of the .fpmc). However ...
(2) A build script may be overkill. I'll keep my ear to the list about
this, if it is decided that it's too much, I'll try another approach
of modifying the original parrot-config, no worries. And admittedly the
"shortcuts people need" list doesn't seem that long.
> >
> > > One thing I didn't address is what kind of shortcuts folks want. I just
> > > have a couple of example shortcuts in the script.
> >
> > Yeah. I was thinking of just
> >
> > --compile
> > --link
> >
> > maybe with shared variants that emit everything needed to create e.g. a
> > t/src/*.c -ish binary.
> >
> > Let's see what other people would need.
>
> for me, this would greatly simplify the mod_parrot build process, though
> i'd like to see it broken down into at least --cflags, --include,
> --ldflags and --libs so we can use our own flags. these options are
I'll check out the build scripts and see what flags will do to compile
the t/src/*.c and put them in. Further, I'll try to determine good
values for --cflags, --include, etc. from the Makefile.
There is a side note here though that should be considered: If somebody
was going to use parrot just in a build directory (which at this point
is probably the most common use) then parrot-config would deliver one
set of values for {--compile, --link, --cflags, --include, etc} where as
if someone installed the program then parrot-config would deliver a
different set of values (in $(EXEC_PREFIX)/bin, $(EXEC_PREFIX)/lib
$(EXEC_PREFIX)/include for example). I suppose one could have a
parrot-config during `make' and leave it in the build directory and then
if someone `make install'ed generate another version and copy it into
$(EXEC_PREFIX)/bin. No?
Best,Pete
