Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install-Boost.ps1 script incompatible with 1.66+ #1040

Open
chwarr opened this issue May 16, 2020 · 5 comments
Open

Install-Boost.ps1 script incompatible with 1.66+ #1040

chwarr opened this issue May 16, 2020 · 5 comments

Comments

@chwarr
Copy link
Member

chwarr commented May 16, 2020

The layout of the Boost NuGet packages that are consumed changed with Boost 1.66.

Until 1.65, they had a lib\native\address-model-32\lib\ directory with the .lib and .dll files for x32. Mutatis mutandis for x64.

After 1.66, they just have a lib\native with both x32 and x64 files in it. The files now have -x32- and -x64- as part of their names.

Adjustments will be needed to make this work with the AppVeyor CMake builds.

(Or perhaps a different model can be used.)

@hs094
Copy link

hs094 commented Feb 24, 2022

I am a Novice Open Source Contributor, can you explain me the details of this feature enhancement?

@chwarr
Copy link
Member Author

chwarr commented Feb 25, 2022

Changes are needed in that Install-Boost.ps1 script's Install-BoostComponent function.

If the Boost version is >= 1.66, then the files that need to be copied to $lib32Dir and $lib64Dir are in the package's lib\native directory with names like *-x32-* and *-x64-*, respectively.

Boost before 1.66 put the DLL and LIB files in different directories for x32 and x64.

The copy logic needs to handle both cases, based on the version of Boost that is being installed.

The script is used by the Windows AppVeyor-based C++ build. The install location of Boost is passed to CMake via the BOOST_ROOT and BOOST_LIBRARYDIR environment variables. I don't know if CMake's FindBoost module needs the DLL and LIB files renamed so they don't have the bitness suffix to work. If it doesn't work, the build will break, so we don't need to worry about a silent bug if a mistake is made. :-)

Hope this helps.

@hs094
Copy link

hs094 commented Feb 25, 2022

Yep. Looking forward to complete this Issue. Thanks @chwarr.

@hs094
Copy link

hs094 commented Mar 1, 2022

Can you please assign this issue to me?

@chwarr
Copy link
Member Author

chwarr commented Mar 2, 2022

Feel free to submit a PR whenever you are ready. We don't tend to use issue assignment in this repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants