mk_native_pbc

[Andrew Whitworth]

As a small nit, why wouldn't we just rewrite it in PIR, or even NQP?
As distutils.pir has shown, we have all the facilities to put together
source files and invoke a compiler available to us from PIR land. We
also have all the information from the config hash readily available
to us as well.

--Andrew Whitworth



On Wed, Apr 21, 2010 at 3:26 PM, Will Coleda <will at coleda.com> wrote:
> I was going to open a ticket on tools/dev/mk_native_pbc, but will hit
> the list first, as this could be several tickets; I'll post a laundry
> list here and get some feedback before opening tickets.
>
>
>
> - is written in sh - We should consider porting it to perl even if it
> will only ever run on platforms with sh. (one less language in our
> build kit.)
>
> - needs documentation - when to run it? why to run it? plans about
> obsoleting it?
>
> - better diagnostic output - should let the developer know that they
> might want to reconfigure and rebuild their parrot when its done. (svn
> commit suggestion missing quotes in output.)
>
> - when it runs, it uses 'perl' instead of the perl Configure ran with.
> (easily fixed with a conversion to perl)
>
> - it discards any options passed to Configure.pl earlier, like those
> involve your compiler (annoying when one of these is an option to
> enable ccache)
>
> - Running it in a freshly built build dir on my machine (r45860)
> (intel mac 10.6) modifies the t/native_pbc/*_4.pbc files - shouldn't
> these be identical if I haven't bumped PBC_COMPAT? (t/pmc/packfile.t
> passes with the new pbc files.)
>
> - running the script executes the tests t/native_pbc/*.t which are all
> disabled. (but not the pack*.t tests which actually depend on the
> modified PBC files)
>
> -if I bump PBC_COMPAT, realclean, rebuild, t/pmc/packfile.t dies with
>
> t/pmc/packfile.t .. 1/34 PackFile_unpack: This Parrot cannot read
> bytecode files with version 6.6.
>
> ok. So let's regen the pbcs...done, files are updated
> (t/native_pbc/*_4.pbc), let's rerun the packfile.t tests - they fail
> with the same message, above... because they're testing the _1 pbcs,
> which weren't updated and are still from the last PBC_COMPAT version -
> so what's broken here, the packfile tests?  mk_native_pbc? (the whole
> process?) Should developers on platforms that don't update the _1 pbcs
> just ignore the packfile tests in situations like this and wait for
> someone on the right platform to regen the tested PBCs ?
>
> Regards.
>
> --
> Will "Coke" Coleda
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>