Re: [proteowizard-developer] new install feature

[Matt C. <mat...@va...>]

B. Frewen wrote:
> Hi Matt,
>
> I'm glad this is a welcome addition.  I know I will make use of it.
>
> I have a few questions inline, below.
>
> On Thu, 8 Jul 2010, Matthew Chambers wrote:
>   
>> The modification you made to package.jam can instead be handled by the 
>> --prefix and --exec-prefix arguments on the bjam command-line, a feature 
>> copied from GNU configure.
>>     
> The change I added was to create a default install location for Windows. 
> I think appropriate default values are important.  Without the change, if 
> the user doesn't specify --prefix, the libraries and headers are installed 
> to C:\<target name>.  I thought C:\pwiz was preferable.  I could set the 
> default elsewhere, instead of in package.jam if you prefer.  Also, I'm not 
> sure what the default location should be for Mac.  Suggestions?
>   
I think c:\include and c:\lib are reasonable defaults for Windows. The 
defaults are supposed to be system-wide, not project-specific. /usr/lib 
and /usr/include are fine defaults on MacOS. The system-wide defaults 
require administrator/root access for all platforms. You can override 
this default with <location> as a requirement of the package.install target.


>> We'll want a tarball artifact for the libraries output and it's trivial 
>> to make the tarball, I'm not sure what the implications are for 
>> redistributing the vendor DLLs without the pwiz tools. Still, a lib 
>> distribution without vendor support compiled in is quite reasonable.
>>     
> How do I do this?  And how urgent is it?  Can it wait for the next 
> iteration?
>   
Just clone the pwiz-bin.tar.bz2 logic into a pwiz-lib.tar.bz2 target and 
a library-tarball-requirements rule. Replace the one mention of 
"executables" in library-tarball-requirements with "libraries". That 
will be fine for the first iteration. But some tarball is desirable for 
the test configuration (it should work just like the subset 
configuration does), so it is needed for the first iteration (if you 
want automated testing of the first iteration). In other words, I would 
be surprised if people who want to use pwiz libraries directly would 
rather download the source and build it themselves than simply download 
the libraries pre-built.


>> We'll also want to have a TeamCity configuration to test that the libs 
>> can be taken and built with those non-boost-build systems. Do you have 
>> an example VC project and Makefile that use the libraries? Nothing 
>> fancy, just something like the pwiz hello example.
>>     
> I can create one.  Where should it go?
>   
Since these files won't be part of the official build system, they don't 
need any consideration in the jamfiles. But I don't see a reason why 
they can't go in the exist pwiz_tools/examples directory. I guess the 
vcproj will need a corresponding sln file, too.


>> Finally, I'm not sure how to take advantage of the boost-subset which 
>> halves the number and size of boost header files. Path.glob[-tree] fed 
>> to package.install is evaluated at parse-time, whereas bcp runs and the 
>> boost subset is copied over at a later phase. It's a difference of 1.5mb 
>> (compressed), so not a big deal though.
>>     
> Sounds like this is something we can solve in the next iteration?
>   
Yes, that's certainly a next iteration thing.


> Also, did you have any comments on the added documentation page?
>   
It's well written, thank you! A similar VC tutorial will make it twice 
as good of course, but that can be in another iteration. :)


> I'll send another patch file once I've added the sample project for 
> TeamCity and set the default locations.
>   
Cool!

Thanks,
-Matt