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 <[email protected]> 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 > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
