As you say in a later post, there are indeed two issues here, the first being the storage system of the modules, the second the use one makes of the files ones they are out of the CPAN system and stored on your local system.

I don't think it is such a bad solution to use the file-system as its storage system. After all the modules are basically just files and unless you really want to change the whole module system as it is implemented on your local Perl installation, I don't see what is wrong with it. Versioning is one issue (perhaps), but that can be handled within the file-system by adding a version number somewhere in the file-name (or perhaps rather in the parent-folder name) or in a 'version'-file somewhere in your module tree.

And of course one should not forget that once the 'raw' files are transformed into perl-modules by the magic of make they are (and must be) simple folders or files, unless you want to change the whole of the module storage concept in Perl.

By sub-contracting as it were, the storage of the 'raw' files and the 'finished' modules to the local filesystem, Perl solves the storage problem in a very elegant, transparant and simple way, which works on all OS'es (as long as they have a file-system with a directory structure of course) without any need to install some OS-dependant program, driver, ... to do this.

Your solution would call for a database system which must work on all types of OS'es for which there is a Perl-installation and finally you store the results after make in the local filesystem anyhow. I'd say Better the devil you know ...

The second issue you raise (one locally installed generic makefile, optimised for your local Perl during installation of Perl6) would shift the burden of writing 'this works everywhere'-makefiles away from the module-writers to the Perl6-makers. I confess that indeed the hurdle of having to write such a makefile has until now stopped me from contributing to CPAN as I cannot test my modules or the makefile on anything other than WIN32-systems and in any case the makefile syntax looks like deep and black magic to me.

However, I think that such a generic makefile will become the next stumbling stone as it will be difficult to guess what (future) modulewriters might require it to be able to do. The fact that writing a makefile is so difficult is perhaps because it is so powerful (I never really tried my hand at it, so I'm just guessing here) and the syntax is so rich and arcane since it must follow this. And whatever this generic makefile's strength might be, it will still have to get some instructions from the 'raw' module files, so from writing a makefile, we go to writing some sort of a config-file. I'm not so sure that that will be easier.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.