-
Notifications
You must be signed in to change notification settings - Fork 3
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
arguments string for vcpkg command #1
Comments
Moreover.... What I have finally is a 'main line' that checks if a toolchain file has been named. |
You're right, that looks suspicious. Although the conversion has been commented out, probably because I ran into problems when using the list-style value. Processing the packages one by one in a loop should be the better solution.
I ran into issues on windows where I configured a x64 build but vcpkg just didn't want to pick that up and proceeded to build as x86. Why am I out of luck then and what do you suggest to do to fix the problem? check_type_size("void*" SIZEOF_VOID_P BUILTIN_TYPES_ONLY)
if (SIZEOF_VOID_P EQUAL 8)
message(STATUS "Using Vcpkg triplet 'x64-windows'")
set(VCPKG_TRIPLET x64-windows)
endif()
For me this line didn't make CMake actually use the toolchain file: set(CMAKE_TOOLCHAIN_FILE ${VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake CACHE STRING "") Only after adding the include it would use it. Any suggestions around that problem? Just removing the Since you seem to have tried a few things and found some of the CMake-script needless, do you mind putting up a Pull Request so I can try your changes on my system and the CI? |
Hi Andre
ARGN is OK because foreach treats semicolon as whitespace.
I always configure cmake for x64 (using cmake-gui). Of course this setting
and the vcpkg triplet are unfortunately independent. If needed I specify
the toolchain file via the "cross compiling" option. The most reliable
way to make vcpkg use the intended architecture is to set
VCPKG_DEFAULT_TRIPLET in the system environment.
Setting a toolchain file name works if the command is in the main line of
the script, but not if it is in a macro function. No need to load that
file.
My version sets a default VCPKG_ROOT and CMAKE_TOOLCHAIN_FILE when
CMAKE_TOOLCHAIN_FILE is undefined, otherwise it extracts the root path from
CMAKE_TOOLCHAIN_FILE and posts it as VCPKG_ROOT (unless it conflicts,
which is fatal). So it can also update a vcpkg defined at higher level.
I eventually made quite a lot of changes, so my version is functionally
different from yours. Burt it relies on your good code for which I thank
you very much.
One change is a loop that runs each install command separately. This lets
me deal with possible vcpkg failures and continue after logging them, and
finally post a variable showing whether all packages are usable or not. I
am still tinkering with that code, but I will create a fork, branch and
pull request soon.
Regards,
-- Tom
…On Sun, Oct 13, 2019 at 11:09 AM Andre Taulien ***@***.***> wrote:
If the first line matters, then shouldn't that ${ARGN} be
${PACKAGES_LIST_STR}?
You're right, that looks suspicious. Although the conversion has been
commented out, probably because I ran into problems when using the
list-style value. Processing the packages one by one in a loop should be
the better solution.
The section to determine the platform architecture is needless, because in
fact you can't force cmake to change the architecture selected at command
level.
I ran into issues on windows where I configured a x64 build but vcpkg just
didn't want to pick that up and proceeded to build as x86. Why am I out of
luck then and what do you suggest to do to fix the problem?
check_type_size("void*" SIZEOF_VOID_P BUILTIN_TYPES_ONLY)
if (SIZEOF_VOID_P EQUAL 8)
message(STATUS "Using Vcpkg triplet 'x64-windows'")
set(VCPKG_TRIPLET x64-windows)
endif()
So is the line that loads the toolchain file. Best to let cmake take care
of that.
For me this line didn't make CMake actually use the toolchain file:
set(CMAKE_TOOLCHAIN_FILE ${VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake CACHE STRING "")
Only after adding the include it would use it. Any suggestions around that
problem? Just removing the include does not work for me.
Since you seem to have tried a few things and found some of the
CMake-script needless, do you mind putting up a Pull Request so I can try
your changes on my system and the CI?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=ACBEZZWYOGYGXPK2ZOILE63QOM2ZXA5CNFSM4I7OKPCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBCYGKA#issuecomment-541426472>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBEZZR52Q5OFYSQCEUTRF3QOM2ZXANCNFSM4I7OKPCA>
.
|
Two possible problems. First, in vcpkg_install_packages you have
# Need the given list to be space-separated #string (REPLACE ";" " " PACKAGES_LIST_STR "${ARGN}")
but then
execute_process( COMMAND ${VCPKG_EXEC} install ${ARGN} WORKING_DIRECTORY ${VCPKG_ROOT} )
If the first line matters, then shouldn't that ${ARGN} be ${PACKAGES_LIST_STR}?
Second, the argument list could become too long for the command processor on 'some systems' (you know which I mean) . It should best be processed in a loop.
The text was updated successfully, but these errors were encountered: