Now you have your idea, let's see some implementation. :)

I generally only expend energies where I have a fairly strong reason to believe that they are going to be useful.

The purpose in mentioning the idea here, rather than say on P5i (or P6meta if that was still active), is to get a feel for whether the idea has any merit. And if it has, then perhaps gather ideas about how it could be used and what form it should take.

My original thought was that using (something like) SQLite which is already ported to a wide variety of platforms and small, and legally unencumbered enough that it could be distributed as a part of the core. As well as providing for this particular usage, having a reasonably capable SQL database as a part of the distribution would itself encourage the use of DBI--which would not be a bad thing I think. It would be great for trying out ideas, prototyping, pilots etc. with the move to a more capable DB once things are working.

I perhaps did not put enough emphasis upon the other part of the notion. That of having a module generic but platform specific module build process. Much of the complexity of the EU::MM/M::B generated makefiles revolves around need to generate makfiles that can copy/move/rename etc in a platform independant way. These modules are already capable of genrating this type of platform independant makefiles for all the platforms where Perl runs.

The problem comes when things don't quite work. Because of the need for these makefiles and the generating process to be platform agnostic, they are (necessarialy) very complex. It makes tracking back through the makefile and the generation process very difficult, and means that changes required by one platform can have undesired side effects upon others.

A platform specific makefile can

1. use that platforms shell commands directly--level 1 reduction in complexity.
2. A platform specific, built at Perl(6/Parrot) install-time makefile would have ready access to all the information used to build the installation. No 'discovery' would be require.--Level 2 complexity reduction.
3. If everything lives in the database, much of the copying/renaming etc would be avoided.

   The current practice of downlooading a gz to a packages directory, Unzipping and untarring to a set of working directories (blib). Building, testing, and then copying everything from the build directories into the installation would (mostly) disappear.

   The sources would be replicated directly into the local DB. The generic makefile would be invoked to perform any compilation required, placing the results back into the DB the first time the package was invoked--which would be when the test scripts (make test) is automatically invoked as a result of the transfer completing.

4. In fact, the vast majority of packages could be built using an appropriate set of inference rules with source and destination being the DB, though the need for a conventional make/makefile might well be eliminated entirely for many packages.

   Can it be harder to write a single generic makefile per platform, than it is to write a single tool capable of generating a generic makefile for every platform?

Yes, it is a blue-sky notion that is ill thought through, but that is why I described it as a notion.

I'd like to go further. I'd like all my application code within the DB also. Id like the compiled bytecode stored there. I'd like to be able to query the DB and discover what applications are using what modules. How often they are loaded. What there memory usage is on a per application/per run basis. That's real blue sky, but doable if you have a DB.

Anyway, the thought was fleeting, and the resistance nearly universal on the basis of what I've seen so far, so like many a good idea, I'll allow it to drift off to the bit-bucket.

Thanks for taking the time to consider it and respond.