Boost.Build V2/General

Configuration Properties - General

Output Directory

This is set to the intermediate directory by default.

If you need any files in a more visible location, use the install action, e.g.

   install output : target1 ... targetN ;

will place target1 through targetN in the output directory. This is useful if you are building one configuration (e.g. msvc-7.1 release) and want easy access to it.

Also, if you are building many different executables and libraries, this can be used to group them all in one place. For example:

   projects/hello/Jamfile?
      exe hello : hello.cpp ;
      install ../bin : hello ;

   projects/world/Jamfile?
      exe world : world.cpp ;
      install ../bin : world ;

will place hello.exe and world.exe in projects/bin. This can be useful for large projects and can be used to locate all files required by an installer (for Windows) or tarred and compressed for packaging with cygwin or Linux.

Intermediate Directory

By default BBv2 places the output in the bin directory of the directory where the Jamfile/target is located. You can change the name of this directory by adding:

  project myproj : build-dir intermediate ;

This will place all the files generated in the intermediate directory. Unlike in Visual Studio, build-dir isn't flat. Subdirectories are created automatically to match the structure of your source tree. If you have a Jamfile in a subdirectory of the one where the build-dir has been specified, the generated files will be placed in a subdirectory of intermediate that matches the subdirectory containing the Jamfile. Thus, if you have:

   projects/Jamfile?
      project projects : build-dir build ;

   projects/hello/Jamfile?
      exe hello : hello.cpp ;

Then hello.obj and hello.exe will be located in projects/build/hello, not projects/build.

Note that the actual location is a subdirectory of this based on the variant, toolset and other options. Thus, hello.exe could be located in projects/build/hello/msvc-7.1/release/rtti-off/hello.obj.

This has advantages over Visual Studio approach:

• You don't need to specify output folders for subprojects;
• Outputs of multiple hello.cpp in different folders of your project don't conflict

Extensions To Delete On Clean

This is controlled by what BBv2 has generated, and not on the extension meaning that BBv2 takes care of what files need deleting. In order to perform a clean, you say

   $ bjam --clean

Configuration Type

1. Makefile

??? [Is this the make target? How does that work? Reference to the documentation?] Makefile project type is a subtype of .vcproj (Visual C++ Build engine) projects. It inherits settings from the property sheets and provides for Configuration- and Platform- specific settings. Similar to the Custom Build Step elements in the other project types, you specify a command line for building. Unlike the other project types you get to specify command lines for Rebuild and Clean as well. In visual studio 8 and 9, rebuild is NOT equivalent to clean, then build. One of the reasons for this is that makefile projects have independent command strings for each target.

2. Application (.exe)

This is controlled by creating an executable target in a Jamfile:

   exe appname : sources.cpp ;

3. Dynamic Library (.dll)

This is controlled by creating a library target in a Jamfile and making it shared:

   lib dllname : sources.cpp : <link>shared <define>_WINDLL ;

The <define>_WINDLL option is there because the IDE adds this as an "inherited definition" to the C/C++ project settings.

4. Static Library (.lib)

This is controlled by creating a library target in a Jamfile and making it static:

   lib libname : sources.cpp : <link>static ;

5. Utility

??? [What does this do?] Projects in Visual Studio are, in the language of other build systems, high-level target consisting of a primary output (usualy a .exe, .dll, or .lib) and they may produce auxiliary outputs as a side-effect of building. The build engine will invoke a project only when it is a (transitive) dependency of the top-level target or when it is one of the top-level targets -- e.g. on Build Solution. Auxiliary output dependencies will not in general cause a project to build but they do contribute to the ordering of the builds among the projects selected to build. A utility project is a .vcproj project with no primary output. It is not eligable to be a "reference" dependency of another project but it can be made an explicit (solution-level) dependency.

Build Browser Information

Yes/No? -- ??? [What do these do?] This is largely obsolete; in earlier studio incarnations source browsing (jump to definition, etc) used one database and intellisense used another. Now they both use the intellisense database but the option to generate the browse database is still there to support any homebrew tools that read that database. Note that there is one setting in the compiler tab and another separate tab for the tool that condenses the database at the project level.

Use of MFC

[TODO: How to create a lib ... ; definition for MFC.] Note that MFC and ATL are now unified but the property sheet still has separate knobs for them.

1. Use Standard Windows Libraries

MFC is not natively supported in BBv2, so you get this option by default.

2. Use MFC in a Static Library

Not natively supported in BBv2. You need to manually add the correct defines, include/library paths, and other settings.

3. Use MFC in a Shared Library

Not natively supported in BBv2. You need to manually add the correct defines, include/library paths, and other settings.

Use of ATL

[TODO: How to create a lib ... ; definition for ATL.]

1. Not Using ATL

ATL is not natively supported in BBv2, so you get this option by default.

2. Static Link to ATL

BBv2:

   <define>_ATL_STATIC_REGISTRY

Not natively supported in BBv2. You need to manually add the correct defines, include/library paths, and other settings.

3. Dynamic Link to ATL

BBv2:

   <define>_ATL_DLL

Not natively supported in BBv2. You need to manually add the correct defines, include/library paths, and other settings.

Minimize CRT Use in ATL

1. No

ATL is not natively supported in BBv2, so you get this option by default.

2. Yes

BBv2:

   <define>_ATL_MIN_CRT

If you want this feature, you can use the following BBv2 code:

   feature atl-minimum-crt : no yes : composite ;
   feature.compose <atl-minumum-crt>yes : <define>_ATL_MIN_CRT ;

Character Set

1. Not Set

BBv2 does not set a specific character set by default. This will default to the narrow/ANSI character set.

2. Use Unicode Character Set

BBv2:

   <define>_UNICODE <define>UNICODE

3. Use Multi-Byte Character Set

BBv2:

   <define>_MBCS

If you want this feature, you can use the following BBv2 code:

   feature character-set : ansi unicode multibyte : composite ;
   feature.compose <character-set>unicode : <define>_UNICODE <define>UNICODE ;
   feature.compose <character-set>multibyte : <define>_MBCS ;

Use Managed Extensions

1. No

BBv2 does not use managed extensions by default.

2. Yes

??? [This uses the /clr switch, but impacts other settings like RTTI and exception handling, so support is non-intuitive.]

Whole Program Optimization

1. No

BBv2 does not do whole program optimization by default.

2. Yes

BBv2:

   <cxxflags>/GL <linkflags>/LTCG

Reference Path

??? [What does this do?] I think this is a managed code (/clr) thing.

[buy lipitor online] [buy lipitor] [[buy lipitor online]]

[buy fioricet online] [buy fioricet] [[buy fioricet online]]