[Shipwright] Shipwright help

sunnavy sunnavy at bestpractical.com
Tue May 17 00:15:12 EDT 2011


in your case, a better solution is to import bioperl-live.git as a git souce
seperately, and then import your package with --skip Bio::Perl

for other c libs, it's good to import them at first too.
when building( ./bin/shipwright-builder ... ), those c libs will be installed
and proper env( LDFLAGS and CFLAGS ) will be set so you don't need to hack
build script at all( but if not in case, you can hack it ).

after the import, require.yml is mainly used in reorder, normally you don't
need it at all, as long as you import things properly, everything will be fine.

best wishes
sunnavy

On 11-05-16 15:22, Benjamin Hitz wrote:
> 
> On May 16, 2011, at 3:13 PM, Benjamin Hitz wrote:
> 
> > 
> > Let's say (real example)
> > I have a git distribution of a perl package which normally depends on a cpan module.  I want to make it depend on the git/repo version of that perl module instead.
> > 
> > The example is I have a perl package (based on a package called Bio-Graphics-Browser2) which depends on Bio-Perl.  However, Bio-Perl (like Gbrowse itself) is highly unstable and often needs to be updated directly from git (or svn, but you follow).
> > 
> > So when I import the main package it has a line for
> > requires: 
> >  cpan-Bio-Perl: 
> >    version blah
> > 
> > I can change this to 
> > requires:
> >  bioperl-live.git: (which is what Shipwright calls the thing when I import the git repo)
> > 
> > Should I set a version?  Or does this map to revision number, or should I leave this blank?
> > 
> > And this is only for perl modules... if I have a perl module that depends on some C program (and a bunch of these do) can I specify in the require.yml or do I have to write a custom build script?
> > 
> > Thanks,
> > Ben
> > 
> >> 
> >> Hi Ben
> >> 
> >> When importing, it's true that Shipwright will run Build.PL, its aim is to
> >> get a more accurate dependency list, no other intensions at all.
> >> you can specify --require-yml to tell Shipwright the dependency directly, in
> >> this case Shipwright won't run Build.PL at all.
> >> I attached an example of require.yml so you know what it looks like.
> >> 
> >> When building, the build script for each dist lives in scripts/dist-name/build,
> >> you can hack it what ever you want, look Shipwright::Manual::CustomizeBuild
> >> for more info about this.
> >> 
> >> 
> >> best wishes
> >> sunnavy
> >> 
> >> On 11-05-13 10:48, Benjamin Hitz wrote:
> >>> Fernan, Nicholas, Sunnavy -
> >>> 
> >>> I have some general questions about Shipwright and in particular trying to import a couple of perl mods:  Bio::DB::BigFile (Bio-BigFile-1.06) and Bio::DB:Sam (Bio-SamTools-1.28).  These are (optional, but I need them) dependencies for other the main application (GBrowse, which has a big tangled dep tree).
> >>> 
> >>> Where I am a little stuck is that Bio-BigFile depends on a C software "package" (actually just 2 files a .h and library for linking) called jkent.   The problem is that the Build.PL for Bio-BigFile is written strangely and interactively.  When shipwright import is run it of course tries to install the cpan package, which in turns looks for the jkent libraries.  I can put the jkent files in the shipyard... but I am not sure how to answer the questions about where to tell BigFile to find the files it needs... It can use an env variable to find them, so I guess there must be some protocol for setting an ENV variable within the shipyard build process.
> >>> 
> >>> I guess what is tripping me up philosophically is that when the Build script is run - it is looking for the libraries ON THE BUILD MACHINE not the final destination... how do I specific "use the libraries that were installed when shipwright installs the jkent from source).    
> >>> 
> >>> Hope that make some amount of sense.  This is my first attempt at using Shipwright, but if it works for this project I would like to use it for some Catalyst apps (yet-to-be-written) as well.
> >>> 
> >>> Also, if there is a mailing list or irc channel, you could point me to it...
> >>> 
> >>> Thanks for your time,
> >>> Ben
> >>> 
> >>> 
> >>> --
> >>> Ben Hitz 
> >>> Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
> >>> Stanford University ** hitz at genome.stanford.edu
> >>> 
> >>> 
> >>> 
> > <require.yml>
> >> 
> > 
> > --
> > Ben Hitz 
> > Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
> > Stanford University ** hitz at genome.stanford.edu
> > 
> > 
> > 
> 
> --
> Ben Hitz 
> Senior Scientific Programmer ** Saccharomyces Genome Database ** GO Consortium
> Stanford University ** hitz at genome.stanford.edu
> 
> 
> 
> _______________________________________________
> Shipwright mailing list
> Shipwright at lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/shipwright


More information about the Shipwright mailing list