Leopold Toetsch (via RT) wrote:
1) We have F<runtime/parrot/include/config.fpmc>, which is a frozen image of the config hash generated by F<config_lib.pasm>. Creating the frozen image needs already parrot (a possibly already existing parrot or miniparrot in the long run). But locating this file needs the library or include path, with resides in this file. We got a typical hen and egg problem.
2) instead of creating e.g. src/revision.c (and possibly other similar files), we create a C-readable representation of the frozen config hash and re-link with that file: src/parrot_config.c. Now we have parrot$EXE with the config inside.
[ ... ]
I've started now implementing this. Done so far:
1) make builds first "miniparrot$(EXE)"[1] which links with src/null_config.o
2) this miniparrot creates the frozen config image
runtime/parrot/include/config.fpmc
3) build_tools/parrot_config_c.pl creates src/parrot_config.c
4) parrot is built, which links with src/parrot_config.o
Next is to make the config available inside parrot.
The runtime path set with Configure --prefix is currently not available.
leo
[1] this isn't really miniparrot, it's all but the config string from src/parrot_config.c, but it should eventually be miniparrot.
