Need for 32- and 64-bit libraries on Windows with suitable naming convention.

[snuchia@…]

From: Beman Dawes <bdawes <at> acm.org> Subject: Re: [1.35.0] Release Candidate 2 available Newsgroups: gmane.comp.lib.boost.devel Date: 2008-03-26 20:58:52 GMT (25 minutes ago)

Stephen Nuchia wrote:

I am using boost in the build of a commercial software package using Microsoft Visual Studio 2008 as the primary build engine. We are building for both 32- and 64-bit targets. There is no mention in the "getting started" documents of how to build the libraries for different bitnesses.

In the VS2008 world the build control files are parameterized with macros, the relevant one of which is $(PlatformName) which has the value "Win32" in 32-bit builds and "x64" in 64-bit builds. To permit maximally "clean" configuration control in the client code tree, the boost libs should live in directories with names based on this convention.

I have manually created lib-Win32 and lib-x64 under the prior release and am in the process of doing the same under RC2. The purpose of this note is to suggest that there is probably a large audience of similarly situated folks who could use at least a breadcrumb in the documentation and, perhaps, some automation. The "installer" for windows should, in my opinion, use the ROOT_DIR/lib-$(PlatformName) convention as well.

Stephen,

This sounds like an important issue, but not one we can address in the 1.35.0 time frame.

Could you please open a trac ticket for it so it isn't lost?

See ​http://svn.boost.org/trac/boost/newticket

Thanks,

--Beman

[anonymous]

This was my first ticket in this system and I missed the "type" field; it should probably be a feature request rather than a bug.

[Vladimir Prus]

The building of 32/64 bit libraries is documented in Boost.Build documentation. Can you please list exact changes that this ticket calls for, as I cannot really make that out?

[Steve Nuchia]

Starting from the index.html in the 1.35.0 RC2 snapshot contained in boost-windows-2008-03-24.zip, I can't find the documentation you're referring to. Following the instructions in more\getting_started\windows.html I find no mention of cross-compilation considerations in general nor this very common special case.

So, it seems to me that there should be a more visible / discoverable link to the documentation that does exist; I still don't know where it is. The "Boost.Build" documentation I've been able to discover is generic and gives no direct help with building boost itself. If you would give me a more specific pointer I will draft some new language for the Windows getting started guide.

The suggested change, beyond documentation, is to provide both sets of compiled libraries, in the build automation and in the pre-compiled installers for Windows, in separate folders named in such a way that they can be selected by the Visual Studio defalt platform selection macro: e.g. lib-Win32 and lib-x64.

It doesn't help that the instructions given don't actually work; when I run bjam (from boost-jam-3.1.16-1-ntx86.zip) from the root of the boost tree I get the error cascade shown below. There has been some traffic on the list about bjam compatibility issues and I hope that's all this is. The RC2 build-from-source automation is, as it stands and as it is documented in the getting started guide, badly broken on Windows. I need some help getting past this before I can make good changes to the guide.

C:\code\Version9\boost> C:\code\Version9\boost>bjam --toolset=msvc stage notice: could not find main target stage notice: assuming it's a name of file to create. C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in attribute warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\project.jam:710: in project.target C:/code/Version9/boost/tools/build/v2\build-system.jam:641: in load C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build C:\code\Version9\boost\boost-build.jam:11: in module scope C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in project.attribut e warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\targets.jam:202: in object(project-t arget)@36.init C:/code/Version9/boost/tools/build/v2/kernel\class.jam:93: in new C:/code/Version9/boost/tools/build/v2/build\project.jam:710: in project.target C:/code/Version9/boost/tools/build/v2\build-system.jam:641: in load C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build C:\code\Version9\boost\boost-build.jam:11: in module scope C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in project.attribut e warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\targets.jam:221: in get C:/code/Version9/boost/tools/build/v2/build\targets.jam:283: in targets-to-build

C:/code/Version9/boost/tools/build/v2/build\targets.jam:252: in object(project-t arget)@36.generate C:/code/Version9/boost/tools/build/v2\build-system.jam:658: in load C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build C:\code\Version9\boost\boost-build.jam:11: in module scope C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in project.attribut e warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\targets.jam:221: in get C:/code/Version9/boost/tools/build/v2/build\targets.jam:284: in targets-to-build

C:/code/Version9/boost/tools/build/v2/build\targets.jam:252: in object(project-t arget)@36.generate C:/code/Version9/boost/tools/build/v2\build-system.jam:658: in load C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build C:\code\Version9\boost\boost-build.jam:11: in module scope don't know how to make <e>stage ...found 1 target... ...can't find 1 target...

C:\code\Version9\boost>

[Vladimir Prus]

​http://boost.org/boost-build2/doc/html/ix01.html has links to 64-bit building instructions for msvc.

Your other point is about building both sets of compiled libraries. As far as pre-compiled installer goes, I think this is outside the scope of this issue. Those installers are provided by BoostConsulting, so you can report the problem directly to them. As for building both sets of libraries, I'm not sure either. I believe 1.35.* will build a single variant by default. You can request extra variants on the command line.

So, that leaves one issue, is that you suggest that 32-bit and 64-bit binaries be placed to different 'stage' directories. Is that right?

As for your last issue -- do you have file C:\code\Version9\boost\Jamroot? It seems like something is seriously wrong with your source tree.

[snuchia@…]

the three files with extension-free names in the root directory are missing from the .zip snapshots at ​http://boost.cowic.de/rc/ ; this would seem to be a flaw in the snapshot packaging process. Perhaps a *.* effect?

With Jamroot in place I'm having much better luck.

The documentation suggested is tantalizing but hardly a step-by-step instruction. It gives some syntax but no clue where I'd put it. It does not look anything like the command line syntax for bjam.

I've been working with open-source software for over twenty years and I've seen some pretty mystifing install instructions. Boost isn't actually bad by the standards of, say, TeX in the late 80's, but the ramp could be smoother. In the previous release I used the makefiles and VS solution files to build Regex and Test manually; we didn't need anything else. Today was my first time to run bjam successfully.

Anyway, thanks for the help. I'll work out in detail what (if anything) I think should be changed and add another note when I'm done.

[snuchia@…]

The built-in Zip handler in Windows Server 2003, x64 edition fails to extract files with no dots in their names. There is no problem with the archives; the documentation recommends against using Microsoft's zip handler on performance grounds anyway but I have been trying to minimize the number of non-standard programs on this machine so I was trying to use it.

More to come. -steve

[Vladimir Prus]

I have checked in a change to make the 'Invocation' section of Boost.Build explicitly list the address-model feature. Now that getting started guide directly links to the invocation section, I think the discovery process is sufficiently streamlined.

As for building both 32-bit and 64-bit libraries by default, this does not seem to be a good idea to me -- we're trying to move away from 'build 8 variants and eat 4GB of disk space' approach take earlier. Therefore, I am not planning to do this. If you disagree, it would be best to discuss this on the mailing list, where real Windows experts and users may be able to comments on approaches.