Re: [Boost-users] boost installer - what should be expected

From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2006-05-30 05:29:59

>On 5/30/06, Sebastian Redl <sebastian.redl_at_[hidden]> wrote:
>
>> These settings are not per-project in VS, at least not typically (I'm
>> not sure whether per-project include paths are even possible). Neither
>> do they hurt, in particular not with Boost, where all headers are in a
>> subdirectory. On the other hand, you _have_ to add the include and
>> library paths, or else hard-code the full path to the Boost includes in
>> the include file names. Nobody does that.
>>
>> Sebastian Redl
>
>There are per-project include paths in VC++ - they're under the
>property 'Additional Include Directories' and are added using the -I
>option of cl.
>
>That's the mechanism by which I add third-party library paths to VC++
>projects - although not hardcoded - I define a whole load of
>environment variables. I'm using VC7.1 - I use Solution Build
>Environment add-in
>(http://www.workspacewhiz.com/OtherAddins.html#SolutionBuildEnvironment)
>to define them, but in VC8.0 there is a built in mechanism (define a
>property sheet using the property manger, define the environment
>variables in the User Macros option) that can be used for that
>purpose.
>
>Why prefer per-project settings, I hear you cry? Well, for older
>projects that used older versions of Boost that I really don't want to
>upgrade! The last time I did that (1.30.0 to 1.32.0, I think),
>upgrading my use of the Boost.Iterator libraries was a bit of a pain.
>
>Oh yeah - there's also per-project library path settings as well -
>they obviously need to be set for Boost libraries needing linking.
>
>Stuart Dootson

I would like to address all issues here in one mail. May be this is the best:

1. Per-Project Setting are deviation from the discussed point, but I see Per-project settings
essential for distributed development, since it is possible (in visual c++) to use relative paths
and manage libs related to the projects with these projects. So one can create a structure:
 my_project_workspace
 |
 +-- thirdparty
 |   +-- boost 1.32
 |   +-- xerces 2.6
 |   +-- xalan x.x
 |
 +-- project files and sub projects

All these projects can reference relative include paths and libs regardless of visual c++
directories set. This way you can compile sources by taking them from version control and calling
build.bat or whatever script without running any fine tuning at the certain system.

2. Why would I need an installer if I can also use zip file. I understand that the installer
downloads pre-build libs which I select. But try to trace how many users download only one
required lib instead of the entire bunch?

3. I think a setup can feature the following selection options:
   - ask the user to register the PATH-EnvVar, so that binary files are automatically found (NSIS
supports it)
   - ask the user to register boost libs in Include path of VC++ (Win32, x64, PocketPC...)
   - ask the user to register boost libs in Lib path of VC++ (Win32, x64, PocketPC...)
There is an article in MSDN how to do that. Please read:
ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vcextall/html/T_Microsoft_VisualStudio_VCProjectEngine_VCPlatform.htm
It relies on .NET, but I think it is now not possible to install the VC++ without .NET Environment.

4. I would select the Windows Installer Technology anyway:
   - Graphical Installer creation Tool is available with Visual C++ (more or less free if you have
VC++)
   - This Technology can be repackaged by other system administrators to deploy boost-libs within
the enterprise (this happens pretty often)
   - Merge Modules can be used to provide users with pre-defined boost distribution components. A
user only needs to select the appropriate MSM-Package to be linked with the application setup.

I understand that these points require a lot, but this would be a "perfect installer".

With Kind Regards,

Ovanes Markarian