From the standpoint of someone developing in PIR, this seems like an arbitrary distinction.
I don't care how the file came to be. If it's an .imc, I'm probably going to want to include it. If it's a .pbc, I'm probably going to want to load_bytecode it. (Of course, this doesn't address the issue of which directory they're in =-)
As we go forward, we shouldn't even have to know /what/ directory these items are in, I suppose, if someone implements the outstanding TODO.
Which I guess is very long winded way of me saying, "eh." =-) Just let me know which parts of the patch (if any) get applied, how things /should/ be, and I can fix up what's left in the Makefile.
Jens Rieks via RT wrote:
On Wednesday 06 October 2004 06:22, Will Coleda wrote:
* side effect of this is that we now build parrotlib.imc into library/, not include/. which makes sense to me, though I could be addled. This required updates to:
It is in include/, because I started to move all generated files to include/, and all hand written files to library/.
include/Getopt_Long.imc is deprecated, I've removed it (a newer version is library/Getopt/Long.imc).
DWIM.imc is the last hand written file in include, I do not know what to do with it.
jens
