Re: solution to TODO #32365

[Leopold Toetsch]

Peter Christopher <pchr...@chem.utoronto.ca> wrote:

> Hi there,

> I have included a script that I think addresses TODO #32365 --
> which was, in short, allow easy shortcuts to build information. The
> script generates a file called parrot-config.pbc in the root directory
> that can search through build information and shortcuts.

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.

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

> Best,Pete

Thanks,
leo

[Jeff Horwitz]

On Mon, 10 Jan 2005, Leopold Toetsch wrote:

[snip]

> 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.
>
> > 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
pretty standard for *-config programs (apr-config, gtk-config, etc.).

-jeff

[Peter Christopher]

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

[Leopold Toetsch]

Peter Christopher <pchr...@chem.utoronto.ca> wrote:

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

Ok. Can you move the build script to F<build_tools> and provide another
patch with the mentioned shortcuts.

Thanks.

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

Yep. We have that problem already with runtime paths. My proposal was to
initially set these paths to build paths and during "make install" redo the
relevant build steps with these paths set to actual installed paths.

> Best,Pete

leo