% 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]

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

Yes, exactly.

beth

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

I don't think there is an existing solution but you should check on the module-build list to be sure.

If I were in in your corner, I would go with 5 (1 + 2 = 5), and keep it perl, something like

% perl build-dist1.pl
creating dist1tempdir
chdir dist1tempdir
copying defaults (README INSTALL LICENSE...)
creating MANIFEST
copying files
creating Module::Build object (like in Build.PL)
dispatch build
dispatch test
dispatch dist
created dist1-0.01.tar.gz successfully
destroying Module::Build object
uploading dist1-0.01.tar.gz
chdir ..
cleaning up dist1tempdir
done!
[download]

See File::Temp, File::Copy,
http://search.cpan.org/~rkobes/ExtUtils-Manifest-1.55/lib/ExtUtils/Manifest.pm#manicopy
http://search.cpan.org/~kwilliams/Module-Build-0.30/lib/Module/Build/Authoring.pod#AUTOMATION
http://search.cpan.org/~kwilliams/Module-Build-0.30/lib/Module/Build/API.pod#dispatch($action,_%args)