Re: [CMake] CMake + Gradle for Android
Hi again Robert,
Would you be able to give me an estimate of how many APK projects you have,
roughly which open source projects you reference via CMake
add_subdirectories, and whether you have any variants beyond the default
Debug and Release? If possible I'd like to approximate your project layout
so we can study it in more closely with an eye toward making the experience
better for this kind of layout.
On Fri, Aug 25, 2017 at 2:46 PM, Jom O'Fisher wrote:
> Targets are specified per-Variation so they need to go under the
> variation-specific section. Probably something like this:
>
> defaultConfig {
> externalNativeBuild {
> cmake {
> targets "library1", "library2"
> }
> }
> }
>
> That should work for you. Let me know.
>
> On Fri, Aug 25, 2017 at 2:42 PM, Robert Dailey
> wrote:
>
>> By the way when I try to use "targets", I get a failure. Basically
>> Gradle doesn't recognize that keyword. I tried singular form as well
>> ("target"), no luck.
>>
>> I'm running canary build of everything possible. What am I missing?
>>
>> On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher
>> wrote:
>> > By gradle module projects, I just mean the leaf build.gradle files as
>> > opposed to the root build.gradle. By configurations, I mean Build Types
>> > (debug vs release) and Product Flavors (demo vs free vs paid).
>> Hereafter I
>> > will use the term "variant" rather than "configuration" to be precise.
>> See
>> > this write-up on build variants:
>> >
>> > https://developer.android.com/studio/build/build-variants.ht
>> ml#build-types
>> >
>> > This build matrix is constructed at the leaf build.gradle level. Native
>> > build in gradle allows you to set C/C++ flags individually for each
>> variant
>> > so that you can define compiler flags (for example, -DFREE_VERSION).
>> >
>> > One thing to notice at this stage is that the same CMake target may be
>> built
>> > with different compiler flags across different projects, build types,
>> and
>> > product flavors. So in the general case, build outputs won't be the
>> same.
>> >
>> > You asked which targets build when specifying path. By default, we
>> build all
>> > targets that produce an .so. You can override this by setting
>> > externalNativeBuild.cmake.targets. For example,
>> >
>> > paid {
>> > ...
>> > externalNativeBuild {
>> > cmake {
>> > ...
>> > targets "native-lib-paid"
>> > }
>> > }
>> > }
>> >
>> > As for your last question, the model we generally see used is that the
>> main
>> > CMakeLists.txt is next to the leaf build.gradle such that this
>> > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt
>> (though
>> > they may share common dependencies and settings). Otherwise, multiple
>> APK
>> > projects would perform pretty much similar to yours--they would build
>> > targets per-leaf project and not share build outputs. As far as I can
>> see
>> > your organization is just as valid so long as you only build the
>> targets you
>> > need.
>> >
>> > Regarding native dependencies between java projects. We generally try to
>> > avoid making the CMake build depend on the gradle build (you should be
>> able
>> > to replicate the CMake build from the command-line if you set the right
>> > flags). At the moment I don't see a way we could make things better
>> without
>> > violating that tenet but that could be lack of imagination on my part.
>> >
>> > We'll definitely be discussing this use case at our next C++ meeting and
>> > I'll also be checking for myself whether ccache will work in this CMake
>> > scenario. If ccache does work it seems like the natural level at which
>> to
>> > fold identical builds.
>> >
>> >
>> >
>> > On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey <
>> rcdailey.li...@gmail.com>
>> > wrote:
>> >>
>> >> I'm not sure what you mean by "gradle module projects", but maybe
>> >> having some examples of what you mean by "configurations, C++ flags,
>> >> etc" might make it more clear.
>> >>
>> >> Question: When specifying "path" for the CMakeLists.txt in the
>> >> build.gradle file, how do you know which targets to build? For
>> >> example, that run of CMake may generate 100 targets, but only 20 need
>> >> to build and be packaged (*.so files) with the APK. Do you just build
>> >> "all"? Is there a way to specify the target itself?
>> >>
>> >> Thanks again. I'd still like to know more about what the ideal
>> >> organization is. I find it hard to believe that large android projects
>> >> rarely break things up into multiple, separate "components" that are
>> >> built independently. That's really the gist of what we're dealing with
>> >> here. Your typical "hello world" project likely will have only 1
>> >> CMakeLists.txt that is pretty self-contained, but all the
>> >> documentation I've looke
Re: [CMake] CMake + Gradle for Android
Targets are specified per-Variation so they need to go under the
variation-specific section. Probably something like this:
defaultConfig {
externalNativeBuild {
cmake {
targets "library1", "library2"
}
}
}
That should work for you. Let me know.
On Fri, Aug 25, 2017 at 2:42 PM, Robert Dailey
wrote:
> By the way when I try to use "targets", I get a failure. Basically
> Gradle doesn't recognize that keyword. I tried singular form as well
> ("target"), no luck.
>
> I'm running canary build of everything possible. What am I missing?
>
> On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher
> wrote:
> > By gradle module projects, I just mean the leaf build.gradle files as
> > opposed to the root build.gradle. By configurations, I mean Build Types
> > (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter
> I
> > will use the term "variant" rather than "configuration" to be precise.
> See
> > this write-up on build variants:
> >
> > https://developer.android.com/studio/build/build-variants.
> html#build-types
> >
> > This build matrix is constructed at the leaf build.gradle level. Native
> > build in gradle allows you to set C/C++ flags individually for each
> variant
> > so that you can define compiler flags (for example, -DFREE_VERSION).
> >
> > One thing to notice at this stage is that the same CMake target may be
> built
> > with different compiler flags across different projects, build types, and
> > product flavors. So in the general case, build outputs won't be the same.
> >
> > You asked which targets build when specifying path. By default, we build
> all
> > targets that produce an .so. You can override this by setting
> > externalNativeBuild.cmake.targets. For example,
> >
> > paid {
> > ...
> > externalNativeBuild {
> > cmake {
> > ...
> > targets "native-lib-paid"
> > }
> > }
> > }
> >
> > As for your last question, the model we generally see used is that the
> main
> > CMakeLists.txt is next to the leaf build.gradle such that this
> > CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt
> (though
> > they may share common dependencies and settings). Otherwise, multiple APK
> > projects would perform pretty much similar to yours--they would build
> > targets per-leaf project and not share build outputs. As far as I can see
> > your organization is just as valid so long as you only build the targets
> you
> > need.
> >
> > Regarding native dependencies between java projects. We generally try to
> > avoid making the CMake build depend on the gradle build (you should be
> able
> > to replicate the CMake build from the command-line if you set the right
> > flags). At the moment I don't see a way we could make things better
> without
> > violating that tenet but that could be lack of imagination on my part.
> >
> > We'll definitely be discussing this use case at our next C++ meeting and
> > I'll also be checking for myself whether ccache will work in this CMake
> > scenario. If ccache does work it seems like the natural level at which to
> > fold identical builds.
> >
> >
> >
> > On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey >
> > wrote:
> >>
> >> I'm not sure what you mean by "gradle module projects", but maybe
> >> having some examples of what you mean by "configurations, C++ flags,
> >> etc" might make it more clear.
> >>
> >> Question: When specifying "path" for the CMakeLists.txt in the
> >> build.gradle file, how do you know which targets to build? For
> >> example, that run of CMake may generate 100 targets, but only 20 need
> >> to build and be packaged (*.so files) with the APK. Do you just build
> >> "all"? Is there a way to specify the target itself?
> >>
> >> Thanks again. I'd still like to know more about what the ideal
> >> organization is. I find it hard to believe that large android projects
> >> rarely break things up into multiple, separate "components" that are
> >> built independently. That's really the gist of what we're dealing with
> >> here. Your typical "hello world" project likely will have only 1
> >> CMakeLists.txt that is pretty self-contained, but all the
> >> documentation I've looked at so far doesn't show the best way to
> >> handle native library dependencies across java projects between
> >> build.gradle files (or maybe I'm just not looking hard enough).
> >>
> >> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher
> >> wrote:
> >> > Thanks for the write-up Robert. Having thought about it, I don't
> believe
> >> > we
> >> > have a satisfying answer at the gradle level for this kind of
> >> > organization.
> >> > In the gradle model module projects are the unit of organization for
> >> > configurations, C/C++ flags, etc. and that's something we're pretty
> much
> >> > stuck with.
> >> > Regarding just t
Re: [CMake] CMake + Gradle for Android
By the way when I try to use "targets", I get a failure. Basically
Gradle doesn't recognize that keyword. I tried singular form as well
("target"), no luck.
I'm running canary build of everything possible. What am I missing?
On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher wrote:
> By gradle module projects, I just mean the leaf build.gradle files as
> opposed to the root build.gradle. By configurations, I mean Build Types
> (debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I
> will use the term "variant" rather than "configuration" to be precise. See
> this write-up on build variants:
>
> https://developer.android.com/studio/build/build-variants.html#build-types
>
> This build matrix is constructed at the leaf build.gradle level. Native
> build in gradle allows you to set C/C++ flags individually for each variant
> so that you can define compiler flags (for example, -DFREE_VERSION).
>
> One thing to notice at this stage is that the same CMake target may be built
> with different compiler flags across different projects, build types, and
> product flavors. So in the general case, build outputs won't be the same.
>
> You asked which targets build when specifying path. By default, we build all
> targets that produce an .so. You can override this by setting
> externalNativeBuild.cmake.targets. For example,
>
> paid {
> ...
> externalNativeBuild {
> cmake {
> ...
> targets "native-lib-paid"
> }
> }
> }
>
> As for your last question, the model we generally see used is that the main
> CMakeLists.txt is next to the leaf build.gradle such that this
> CMakeLists.txt doesn't couple with peer APK project CMakeLists.txt (though
> they may share common dependencies and settings). Otherwise, multiple APK
> projects would perform pretty much similar to yours--they would build
> targets per-leaf project and not share build outputs. As far as I can see
> your organization is just as valid so long as you only build the targets you
> need.
>
> Regarding native dependencies between java projects. We generally try to
> avoid making the CMake build depend on the gradle build (you should be able
> to replicate the CMake build from the command-line if you set the right
> flags). At the moment I don't see a way we could make things better without
> violating that tenet but that could be lack of imagination on my part.
>
> We'll definitely be discussing this use case at our next C++ meeting and
> I'll also be checking for myself whether ccache will work in this CMake
> scenario. If ccache does work it seems like the natural level at which to
> fold identical builds.
>
>
>
> On Wed, Aug 23, 2017 at 1:03 PM, Robert Dailey
> wrote:
>>
>> I'm not sure what you mean by "gradle module projects", but maybe
>> having some examples of what you mean by "configurations, C++ flags,
>> etc" might make it more clear.
>>
>> Question: When specifying "path" for the CMakeLists.txt in the
>> build.gradle file, how do you know which targets to build? For
>> example, that run of CMake may generate 100 targets, but only 20 need
>> to build and be packaged (*.so files) with the APK. Do you just build
>> "all"? Is there a way to specify the target itself?
>>
>> Thanks again. I'd still like to know more about what the ideal
>> organization is. I find it hard to believe that large android projects
>> rarely break things up into multiple, separate "components" that are
>> built independently. That's really the gist of what we're dealing with
>> here. Your typical "hello world" project likely will have only 1
>> CMakeLists.txt that is pretty self-contained, but all the
>> documentation I've looked at so far doesn't show the best way to
>> handle native library dependencies across java projects between
>> build.gradle files (or maybe I'm just not looking hard enough).
>>
>> On Wed, Aug 23, 2017 at 1:02 PM, Jom O'Fisher
>> wrote:
>> > Thanks for the write-up Robert. Having thought about it, I don't believe
>> > we
>> > have a satisfying answer at the gradle level for this kind of
>> > organization.
>> > In the gradle model module projects are the unit of organization for
>> > configurations, C/C++ flags, etc. and that's something we're pretty much
>> > stuck with.
>> > Regarding just the redundant build issue, would something like ccache
>> > help?
>> > I know people have used it with ndk-build with success, I'm not sure
>> > about
>> > CMake but I don't see why that should make a difference.
>> >
>> >
>> >
>> > On Tue, Aug 22, 2017 at 10:27 AM, Robert Dailey
>> >
>> > wrote:
>> >>
>> >> Another reason to reduce the number of binary directories is that
>> >> there are different ways of managing third party libraries. One in
>> >> particular that we use is to clone a repository into the binary
>> >> directory and build all third party libs in real time based on a
>> >> toolchain file (Similar to the functionality provided by
>> >> ExternalProject module in CMake). This is re
Re: [CMake] Should configuration package files define module package variables?
Doh, forgot the links I intended to reference in my original email:
[1]: https://cmake.org/cmake/help/v3.6/command/find_package.html
[2]:
https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-packages
[3]: https://cmake.org/cmake/help/v3.6/module/CMakePackageConfigHelpers.html
On Fri, Aug 25, 2017 at 11:21 AM, Robert Dailey
wrote:
> So I've been studying the find_package[1] and "creating packages"[2]
> documentation, as well as the CMakePackageConfigHelpers[3] page.
>
> Based on the current offerings of configuration packages, I do not
> understand the need for the relocatable config.cmake file when all it
> really contains is:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
>
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables? Example of what foo-config.cmake would be like:
>
> include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
> set( Foo_INCLUDE_DIRS "... path here" )
> set( Foo_LIBRARIES "List of libraries here..." )
>
>
> Is this necessary? Honestly the learning curve for creating packages
> for find_package is very steep. I did not see any general advice on
> this kind of stuff. It seems like Module packages are being deprecated
> in favor of Config packages, because it puts the responsibility of
> maintaining find package logic on the upstream maintainer (config
> package) instead of on CMake (module packages it ships with).
>
> Thanks in advance for any help.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Should configuration package files define module package variables?
So I've been studying the find_package[1] and "creating packages"[2]
documentation, as well as the CMakePackageConfigHelpers[3] page.
Based on the current offerings of configuration packages, I do not
understand the need for the relocatable config.cmake file when all it
really contains is:
include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
However, what I'm wondering is even though the import targets should
contain all information about include directories, libraries, etc,
should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
variables? Example of what foo-config.cmake would be like:
include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake)
set( Foo_INCLUDE_DIRS "... path here" )
set( Foo_LIBRARIES "List of libraries here..." )
Is this necessary? Honestly the learning curve for creating packages
for find_package is very steep. I did not see any general advice on
this kind of stuff. It seems like Module packages are being deprecated
in favor of Config packages, because it puts the responsibility of
maintaining find package logic on the upstream maintainer (config
package) instead of on CMake (module packages it ships with).
Thanks in advance for any help.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Please update the documentation for execute_process
Am 25.08.2017 um 16:12 schrieb Jeffrey Walton:
Below is a typical case for us
(https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If
it looks pretty shitty, it probably is. That's the best we have been
able to come up with based on the documentation.
Below is the example code. We don't know whether it should be:
set(SHELL_CMD sh)
set(SHELL_ARGS -c)
set(GREP_CMD egrep)
set(GREP_ARGS -i -c)
execute_process(COMMAND ${SHELL_CMD} ${SHELL_ARGS}
"${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
Or:
COMMAND "${SHELL_CMD}", "${CMAKE_CXX_COMPILER}", "-dumpmachine", "2>&1"
Or:
COMMAND "${SHELL_CMD}" "${CMAKE_CXX_COMPILER}" "-dumpmachine" "2>&1"
Or:
set(SHELL_CMD sh)
set(GREP_CMD egrep)
execute_process(COMMAND ${SHELL_CMD} "-c" "${CMAKE_CXX_COMPILER}
"-dumpmachine" "2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "-i" "-c" "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
And we certainly don't know what to do with "2>&1" because there is no example.
The documentation states
"If OUTPUT_VARIABLE or ERROR_VARIABLE are given the variable named will
be set with the contents of the standard output and standard error pipes
respectively. If the same variable is named for both pipes their output
will be merged in the order produced
so I would suspect to use something like
execute_process(COMMAND "${CMAKE_CXX_COMPILER}"
"-dumpmachine" OUTPUT_VARIABLE output_dump ERROR_VARIABLE output_dump)
and then use a
if( output_dump MATCHES "amd64" )
..
endif()
block
Does that work?
Jeff
**
set(SHELL_CMD sh -c)
set(GREP_CMD egrep -i -c)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x86_64"
OUTPUT_VARIABLE CRYPTOPP_X86_64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "i.86"
OUTPUT_VARIABLE CRYPTOPP_I386
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW32
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "w64-mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x32"
OUTPUT_VARIABLE CRYPTOPP_X32
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch32"
OUTPUT_VARIABLE CRYPTOPP_AARCH32
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch64"
OUTPUT_VARIABLE CRYPTOPP_AARCH64
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://stackoverflow.com/q/12515462/608639
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "\\"
OUTPUT_VARIABLE CRYPTOPP_ARM
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARMHF"
OUTPUT_VARIABLE CRYPTOPP_ARMHF
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARM7L"
OUTPUT_VARIABLE CRYPTOPP_ARM7L
OUTPUT_STRIP_TRAILING_WHITESPACE)
# Fixup?
if ("${CRYPTOPP_MINGW64}" STREQUAL "1")
unset(CRYPTOPP_MINGW32)
endif()
# MinGW32
if ("${CRYPTOPP_MINGW32}" STREQUAL "1")
set(CRYPTOPP_I386 "1")
endif()
# OpenBSD and MinGW64
if ("${CRYPTOPP_X86_64}" STREQUAL "1" OR "${CRYPTOPP_MINGW64}" STREQUAL "1")
set(CRYPTOPP_AMD64 "1")
endif()
# arm7l is another 32-bit hard float machine. RPI-3 is arm7l on 64-bit hardware
if ("${CRYPTOPP_ARM}" STREQUAL "1" OR "${CRYPTOPP_ARM7L}" STREQUAL "1")
set(CRYPTOPP_ARMHF "1")
endif()
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Please update the documentation for execute_process
> Below is a typical case for us
> (https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If
> it looks pretty shitty, it probably is. That's the best we have been
> able to come up with based on the documentation.
Below is the example code. We don't know whether it should be:
set(SHELL_CMD sh)
set(SHELL_ARGS -c)
set(GREP_CMD egrep)
set(GREP_ARGS -i -c)
execute_process(COMMAND ${SHELL_CMD} ${SHELL_ARGS}
"${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
Or:
COMMAND "${SHELL_CMD}", "${CMAKE_CXX_COMPILER}", "-dumpmachine", "2>&1"
Or:
COMMAND "${SHELL_CMD}" "${CMAKE_CXX_COMPILER}" "-dumpmachine" "2>&1"
Or:
set(SHELL_CMD sh)
set(GREP_CMD egrep)
execute_process(COMMAND ${SHELL_CMD} "-c" "${CMAKE_CXX_COMPILER}
"-dumpmachine" "2>&1"
COMMAND ${GREP_CMD} ${GREP_ARGS} "-i" "-c" "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
And we certainly don't know what to do with "2>&1" because there is no example.
Jeff
**
set(SHELL_CMD sh -c)
set(GREP_CMD egrep -i -c)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "amd64"
OUTPUT_VARIABLE CRYPTOPP_AMD64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x86_64"
OUTPUT_VARIABLE CRYPTOPP_X86_64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "i.86"
OUTPUT_VARIABLE CRYPTOPP_I386
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW32
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://github.com/weidai11/cryptopp/issues/466
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "w64-mingw32"
OUTPUT_VARIABLE CRYPTOPP_MINGW64
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "x32"
OUTPUT_VARIABLE CRYPTOPP_X32
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch32"
OUTPUT_VARIABLE CRYPTOPP_AARCH32
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "Aarch64"
OUTPUT_VARIABLE CRYPTOPP_AARCH64
OUTPUT_STRIP_TRAILING_WHITESPACE)
# http://stackoverflow.com/q/12515462/608639
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "\\"
OUTPUT_VARIABLE CRYPTOPP_ARM
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARMHF"
OUTPUT_VARIABLE CRYPTOPP_ARMHF
OUTPUT_STRIP_TRAILING_WHITESPACE)
execute_process(COMMAND ${SHELL_CMD} "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
COMMAND ${GREP_CMD} "ARM7L"
OUTPUT_VARIABLE CRYPTOPP_ARM7L
OUTPUT_STRIP_TRAILING_WHITESPACE)
# Fixup?
if ("${CRYPTOPP_MINGW64}" STREQUAL "1")
unset(CRYPTOPP_MINGW32)
endif()
# MinGW32
if ("${CRYPTOPP_MINGW32}" STREQUAL "1")
set(CRYPTOPP_I386 "1")
endif()
# OpenBSD and MinGW64
if ("${CRYPTOPP_X86_64}" STREQUAL "1" OR "${CRYPTOPP_MINGW64}" STREQUAL "1")
set(CRYPTOPP_AMD64 "1")
endif()
# arm7l is another 32-bit hard float machine. RPI-3 is arm7l on 64-bit hardware
if ("${CRYPTOPP_ARM}" STREQUAL "1" OR "${CRYPTOPP_ARM7L}" STREQUAL "1")
set(CRYPTOPP_ARMHF "1")
endif()
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Please update the documentation for execute_process
The documentation for execute_process has some room for improvement. We recently got burned by a problem that has existed since at least 2011: https://stackoverflow.com/q/6797395/608639 . Once we learned the problem we could research a bit. The problem cost us over 8 man hours when it should not have been a problem in the first place. Considering there's nothing special about us, it has probably wasted thousands of man hours over the years. Here are the actionable items for the execute_process documentation task: * please clearly state the first argument is the command only, and not command + arguments * please clearly state whether arguments need to be quoted * please clearly state whether arguments need to be comma separated * please provide an example (or examples) to show how to specify multiple arguments for a command * please provide an example (or examples) to show how to redirect output when using a command Below is a typical case for us (https://github.com/weidai11/cryptopp/blob/master/CMakeLists.txt). If it looks pretty shitty, it probably is. That's the best we have been able to come up with based on the documentation. ** -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1
Hello I confirmed this is fixed. I used 9538d22d955a0b101548019003f2d5c7ba833d77 for the check. Brad King wrote: On 08/23/2017 05:07 AM, masaru tsuchiyama wrote: It seems your coworker can reproduce it and you can use the PC tomorrow. So I don't need to debug it, right? Correct, thanks. See issue for further updates. -Brad -- Masaru Tsuchiyama -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
