in reply to putting perl and modules in your source code repository
How you're going to do this will largely depend on the infrastructure you have available. For example, we simply installed global perl's in /some_share/$platID, and then have some logic in shell to pick the current platform ID based on uname, etc. However, what we haven't done is automate the building of anything (though I've cried for it).
What I'd prefer seeing is that the perl source was put into its own repository/branch/whatever that we could build on each platform. And that part of this was that we could insert new CPAN tarballs into the mix, and simply rebuild on each platform and reinstall.
In the meantime, since I can't easily add modules to the global perl trees, I simply check in the tarballs to the build, and have make run my preparation script which untars them and runs Makefile.PL/make/make install or Build.PL/build/build install as appropriate to install to the build directory (i.e., a private lib directory). But I'd like to be able to submit it globally, and, using a form of continuous integration, get it applied to the global perls automatically.
As for your last question, "prove" is a good way to determine if a given build of perl is compatible. If the unit tests run clean, it's probably sufficient (assuming adequate unit test coverage). But I'm going to end here before I head into a full-blown rant.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: putting perl and modules in your source code repository
by perl5ever (Pilgrim) on Apr 13, 2009 at 20:42 UTC |