Thank-you for taking the time to consider my question, but it isn't quite what I am looking for. My question concerns the process used to create what is uploaded to CPAN, not its final form.

As for the final form: A bundle isn't really necessary in this case. Once the tarballs are constructed and uploaded to CPAN, it is pretty easy to insure that downloading an extension tarball triggers the downloading of the core package. Each CPAN package merely needs to declare the core package as a prerequisite. Once that is done, any user who instructs CPAN/CPAN-PLUS to follow all prerequisites will automatically download the core module along with the desired extensions.

My question concerns the process used to create what is uploaded to CPAN, not its final form.
Could have fooled me :) Maybe this

% cd one-dist
% perl Build.PL
% perl build dist
% cpan-upload -verbose one-dist-0.1.tar.gz
% cd ..
% cd two-dist
% perl Build.PL
% perl build dist
% cpan-upload -verbose two-dist-0.1.tar.gz
[download]

if thats not it, maybe you can explain better what you're asking :)

I think he wants to know how do this:

% cd dist
% perl Build.PL
% perl build dist
% ls
one-dist-0.1.tar.gz
two-dist-0.1.tar.gz
[ ... ]
[download]

--
David Serrano

cd one-dist...cd two-dist won't work for us without a massive restructuring of our repository. All of our code is in one lib directory, e.g. ourstuff/lib. All the examples I have found for Module::Build indicate that Module::Build expects to find both Build.PL and lib in the same directory, that is:

one-dist/Build.PL
one-dist/lib
two-dist/Build.PL
two-dist/lib
[download]

There are, of course, lots of ways to handle this problem, but none of them a quick fix:

   solution 1:
   % perl Build1.PL
   % perl Build2.PL ...
  
   solution 2:
   % cd staging/one-dist
   % ln -s ourstuff/lib staging/one-dist
   % perl Build.PL ...

   solution 3: supplement Module::Build with make or ant
   solution 4: use Module::Build as an API and write
     some sort of software around it
[download]

Solution 1 has the problem that other files (e.g. MANIFEST-SKIP) would all have to be specially named so that the right files were used with the right build script. Seems like a pretty hard approach to get right given the complexity of Module::Build.

Solution 2 means playing around with the file system - better than restructuring a repository or second guessing Module::Build, but not really to my liking. It has to be redone each time someone sets up a fresh work area. Even if its scripted, it still makes assumptions about how people configure their work environment (usually a pretty personal decision for most programmers). OK, we can set standards, but now we're into a process that is as much political as technical.

If solution 2 is the way to go this, solution 3 might be a good way to implement it - at least both ant and make provide a framework that separates configuration data from configuration instructions. And they don't mess up the end-user because ant/make are only being used to build the uploaded files and play no role in downloading and installation. But adding ant/make into the mix makes the build process that much more complicated and harder to maintain going forward.

Solution 4 essentially involves writing yet another perl module. But I don't really want to do that unless I've genuinely stumbled on a problem that doesn't have an existing solution. There are too many things that need inventing to waste time on recreating the wheel.

Thanks, beth