Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-22 19:49+0200 Sebastian Holtermann wrote:
[...]
Actually I made an implementation in 3.6.0 that generated the moc files
in the a build tree subdirectory correspoding to the header path.
But that blew up on some projects because the generated paths got too long
for some compiĺers. That implementation was theefore reverted.
In 3.7 there is a new approatch that generates the moc files in
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
This ensures that the paths don't get too long and that there won't be any
name collisions.
Hi Sebastian:
After a substantial break to finish off a different project, I have
now had a chance to return to the present topic using my attached
test_automoc project. (Also available in the cmake/test_automoc
subdirectory of the PLplot git master branch that can be accessed at
) states the
following:
"However, if multiple source files in different directories do this
[i.e., contain an "#include "moc_.cpp" when the header
name is .h] then their generated moc files would
collide. In this case a diagnostic will be issued."
For the life of me, I cannot find a way to generate that diagnostic.
Instead, three different targets (two targets concerning the same
implementation code and header in the same directory and a third
target for a copy of that same implementation code and header in a
different directory) generate at build time a file named
moc_test_q_object.cpp in the same build directory at different times.
This is a clear example of a three-way name collision, but CMake does
not issue a diagnostic for any of these targets concerning that
collision contrary to the above documentation.
Could you please take a look at the three last executables configured
for this test case (helloworld_automoc_same_include,
helloworld_automoc_same_include1, and
helloworld_automoc_same_include2) to see why that collision diagnostic
is not being issued with cmake-3.7.0? Better yet, of course, would be
to solve these remaining name collisions completely by using a
modification of your idea above, i.e., for this special case where
users implementation code contained
#include "moc_.cpp"
then moc should generate the file
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp
Note, the generated moc file has the name expected by the #include so
I believe this idea would work so long as automoc automatically
appended
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to
the target INCLUDE_DIRECTORIES property.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
test_automoc.tar.gz
Description: Simple project to test automoc for various header file locations and names
--
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-developers
Re: [cmake-developers] Android variables
On 13-Nov-16 00:48, Florent Castelli wrote:
> On 12/11/2016 13:35, Ruslan Baratov wrote:
>> On 12-Nov-16 19:09, Florent Castelli wrote:
>>> On 12/11/2016 06:53, Ruslan Baratov wrote:
On 12-Nov-16 08:21, Florent Castelli wrote:
> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
>> Hi,
>>
>> I wonder if it's possible to introduce next variables describing
>> Android
>> tools:
>> * C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that
>> will
>> contain the path to preprocessor. Example:
>>* CMAKE_CXX_COMPILER =
>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
>>
>>
>>* CMAKE_C_PREPROCESSOR =
>> /toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
>>
>>
>> * ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
>> variable mean but it's an important part of move from taka-no-me
>> toolchain to CMake 3.7. I guess it's like
>>* CMAKE_CXX_COMPILER =
>> /toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
>>
>>
>>
>> Of course if I'm not missing something and they are not already
>> somewhere :)
>>
>> Ruslo
> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
I have no idea and not planning to test it because the old code was
using `cpp` preprocessor and I see no point of changing it.
>>> Well, you can define your preprocessor to be "${CMAKE_C_COMPILER}
>>> -E" locally and it will work with GCC-like compilers.
>>> That's a more robust way to call it as there is no
>>> CMAKE_C_PREPROCESSOR standard value in any CMake file.
>>> Nobody should call "cpp" manually anymore, but use the compiler
>>> driver instead to do it for you.
>>>
>>> That's why there's no standard CPP variable in CMake, it's not
>>> needed at all.
>>> For the same reasons, you rarely have to call the linker directly,
>>> it's usually done through the compiler driver.
>> Just like I said I'm not using it - this variable needed for 3rd
>> party package. I have no idea how it was used, the only thing I know
>> is that if I remove this variable the package stop working.
> Then just set it yourself as I said. You don't even need 3.7.0, you
> can just override it in the current version of CMake and previous
> toolchain you used.
I'm trying to move to 3.7.0 variables (that now became standard) and
drop old toolchain. And you're giving me advice to not rely on 3.7.0 and
use previous toolchain?
> The 3rd party package using it should still work.
> Use small incremental steps, in order to migrate. It will be easier.
That's exactly what I'm doing now.
>
>>
>>>
> Calling it directly is kind of dangerous though since you will
> probably be missing the proper language information and other options
> that might affect the predefined preprocessor defines.
I'm not calling it directly, it was used by `configure` script of
3rd party.
> gcc has different binaries for different target archs and has some
> defines baked in, but this won't apply to Clang that uses only one
> binary and a target triple.
For clang based android toolchain the
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
variable points to the directory with gcc, so it will find `cpp`
preprocessor too. I don't know if it's good or bad :)
>>>
>>> I think that's an implementation detail you shouldn't rely on. The
>>> compilers in the NDK are changing, GCC is deprecated and you
>>> shouldn't expect that.
>>> Clang is mostly self contained and using very little from the GCC
>>> distribution (binutils), it will be gone at some point, so you
>>> should be ready for the future.
>> My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't
>> bother about the destiny of GCC distribution. When this stuff will
>> change the problems will appear in both taka-no-me and CMake 3.7+.
> Well, you should care as the cpp program will likely disappear and you
> will need other means to preprocess anything directly (gcc/clang -E).
> Better do it now and break one of the last dependency you have and
> migrate away from old custom variables.
There are a lot of "small" and "obvious" things to improve during
migration, however I will never end it if I will rush to fix them all.
I'm focused now on using new variables. Just like you said "Use small
incremental steps".
>
>>
>>>
>>> If you're updating CMake and changing the toolchain file, then I
>>> would expect that some work has to be done, including making changes
>>> to the invocation of a 3rd party script that is using custom
>>> variables from the old toolchain.
>> There is a tricky part about that. I do define variables like
>> CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me
>> back CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But
>> CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only a
Re: [cmake-developers] Android variables
On 12/11/2016 13:35, Ruslan Baratov wrote:
On 12-Nov-16 19:09, Florent Castelli wrote:
On 12/11/2016 06:53, Ruslan Baratov wrote:
On 12-Nov-16 08:21, Florent Castelli wrote:
On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
Hi,
I wonder if it's possible to introduce next variables describing
Android
tools:
* C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that
will
contain the path to preprocessor. Example:
* CMAKE_CXX_COMPILER =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
* CMAKE_C_PREPROCESSOR =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
* ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
variable mean but it's an important part of move from taka-no-me
toolchain to CMake 3.7. I guess it's like
* CMAKE_CXX_COMPILER =
/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
Of course if I'm not missing something and they are not already
somewhere :)
Ruslo
How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
I have no idea and not planning to test it because the old code was
using `cpp` preprocessor and I see no point of changing it.
Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E"
locally and it will work with GCC-like compilers.
That's a more robust way to call it as there is no
CMAKE_C_PREPROCESSOR standard value in any CMake file.
Nobody should call "cpp" manually anymore, but use the compiler
driver instead to do it for you.
That's why there's no standard CPP variable in CMake, it's not needed
at all.
For the same reasons, you rarely have to call the linker directly,
it's usually done through the compiler driver.
Just like I said I'm not using it - this variable needed for 3rd party
package. I have no idea how it was used, the only thing I know is that
if I remove this variable the package stop working.
Then just set it yourself as I said. You don't even need 3.7.0, you can
just override it in the current version of CMake and previous toolchain
you used. The 3rd party package using it should still work.
Use small incremental steps, in order to migrate. It will be easier.
Calling it directly is kind of dangerous though since you will
probably be missing the proper language information and other options
that might affect the predefined preprocessor defines.
I'm not calling it directly, it was used by `configure` script of
3rd party.
gcc has different binaries for different target archs and has some
defines baked in, but this won't apply to Clang that uses only one
binary and a target triple.
For clang based android toolchain the
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
variable points to the directory with gcc, so it will find `cpp`
preprocessor too. I don't know if it's good or bad :)
I think that's an implementation detail you shouldn't rely on. The
compilers in the NDK are changing, GCC is deprecated and you
shouldn't expect that.
Clang is mostly self contained and using very little from the GCC
distribution (binutils), it will be gone at some point, so you should
be ready for the future.
My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't
bother about the destiny of GCC distribution. When this stuff will
change the problems will appear in both taka-no-me and CMake 3.7+.
Well, you should care as the cpp program will likely disappear and you
will need other means to preprocess anything directly (gcc/clang -E).
Better do it now and break one of the last dependency you have and
migrate away from old custom variables.
If you're updating CMake and changing the toolchain file, then I
would expect that some work has to be done, including making changes
to the invocation of a 3rd party script that is using custom
variables from the old toolchain.
There is a tricky part about that. I do define variables like
CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me back
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after**
toolchain processed hence I can't use such variable in toolchain to
create my custom variables. So if we want to have everything play nice
this should be defined in CMake.
Why do you need that variable to be defined in the toolchain? It
shouldn't be a problem to define it outside of it or just before you use
the 3rd party package that is using it.
Overall, I consider that taka-no-me Android toolchain to be tech
debt. It hasn't been updated for a long time, doesn't work with
recent NDK (unless you resort to use a standalone toolchain), locks
people with some custom variables making them believe they are
standard and has tons of other small bugs and issues.
I understand its appeal for most people, but to me, it has caused
more trouble than help.
Just like I said before, those variables needed in 3rd party tools
whic
Re: [cmake-developers] Android variables
On 12-Nov-16 19:09, Florent Castelli wrote:
> On 12/11/2016 06:53, Ruslan Baratov wrote:
>> On 12-Nov-16 08:21, Florent Castelli wrote:
>>> On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
Hi,
I wonder if it's possible to introduce next variables describing
Android
tools:
* C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will
contain the path to preprocessor. Example:
* CMAKE_CXX_COMPILER =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
* CMAKE_C_PREPROCESSOR =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
* ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
variable mean but it's an important part of move from taka-no-me
toolchain to CMake 3.7. I guess it's like
* CMAKE_CXX_COMPILER =
/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
Of course if I'm not missing something and they are not already
somewhere :)
Ruslo
>>> How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
>> I have no idea and not planning to test it because the old code was
>> using `cpp` preprocessor and I see no point of changing it.
> Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E"
> locally and it will work with GCC-like compilers.
> That's a more robust way to call it as there is no
> CMAKE_C_PREPROCESSOR standard value in any CMake file.
> Nobody should call "cpp" manually anymore, but use the compiler driver
> instead to do it for you.
>
> That's why there's no standard CPP variable in CMake, it's not needed
> at all.
> For the same reasons, you rarely have to call the linker directly,
> it's usually done through the compiler driver.
Just like I said I'm not using it - this variable needed for 3rd party
package. I have no idea how it was used, the only thing I know is that
if I remove this variable the package stop working.
>
>>> Calling it directly is kind of dangerous though since you will
>>> probably be missing the proper language information and other options
>>> that might affect the predefined preprocessor defines.
>> I'm not calling it directly, it was used by `configure` script of 3rd
>> party.
>>
>>> gcc has different binaries for different target archs and has some
>>> defines baked in, but this won't apply to Clang that uses only one
>>> binary and a target triple.
>> For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
>> variable points to the directory with gcc, so it will find `cpp`
>> preprocessor too. I don't know if it's good or bad :)
>
> I think that's an implementation detail you shouldn't rely on. The
> compilers in the NDK are changing, GCC is deprecated and you shouldn't
> expect that.
> Clang is mostly self contained and using very little from the GCC
> distribution (binutils), it will be gone at some point, so you should
> be ready for the future.
My goal now is to move from taka-no-me to CMake 3.7+ Android. I don't
bother about the destiny of GCC distribution. When this stuff will
change the problems will appear in both taka-no-me and CMake 3.7+.
>
> If you're updating CMake and changing the toolchain file, then I would
> expect that some work has to be done, including making changes to the
> invocation of a 3rd party script that is using custom variables from
> the old toolchain.
There is a tricky part about that. I do define variables like
CMAKE_SYSTEM_VERSION or CMAKE_ANDROID_ARCH_ABI and CMake gives me back
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX. But
CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX is only available **after** toolchain
processed hence I can't use such variable in toolchain to create my
custom variables. So if we want to have everything play nice this should
be defined in CMake.
> Overall, I consider that taka-no-me Android toolchain to be tech debt.
> It hasn't been updated for a long time, doesn't work with recent NDK
> (unless you resort to use a standalone toolchain), locks people with
> some custom variables making them believe they are standard and has
> tons of other small bugs and issues.
> I understand its appeal for most people, but to me, it has caused more
> trouble than help.
Just like I said before, those variables needed in 3rd party tools which
is not related neither to CMake nor to taka-no-me toolchain. I see no
point of discussing issues you have with taka-no-me toolchain.
> It could have been done so much better.
It's open source world. From my opinion every question like "why it's
not so good?" should really be "why I'm not improving it?" or "why I'm
not doing something better?".
Ruslo
--
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
informatio
Re: [cmake-developers] Android variables
On 12/11/2016 06:53, Ruslan Baratov wrote:
On 12-Nov-16 08:21, Florent Castelli wrote:
On 10/11/2016 16:05, Ruslan Baratov via cmake-developers wrote:
Hi,
I wonder if it's possible to introduce next variables describing Android
tools:
* C preprocessor. Similar to CMAKE_CXX_COMPILER the variable that will
contain the path to preprocessor. Example:
* CMAKE_CXX_COMPILER =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
* CMAKE_C_PREPROCESSOR =
/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-cpp
* ANDROID_TOOLCHAIN_MACHINE_NAME. In fact I'm not sure what this
variable mean but it's an important part of move from taka-no-me
toolchain to CMake 3.7. I guess it's like
* CMAKE_CXX_COMPILER =
/toolchains/${ANDROID_TOOLCHAIN_MACHINE_NAME}-4.9/prebuilt/linux-x86_64/bin/${ANDROID_TOOLCHAIN_MACHINE_NAME}-g++
Of course if I'm not missing something and they are not already
somewhere :)
Ruslo
How about ${CMAKE_C/CXX_COMPILER} -E to call the preprocessor?
I have no idea and not planning to test it because the old code was
using `cpp` preprocessor and I see no point of changing it.
Well, you can define your preprocessor to be "${CMAKE_C_COMPILER} -E"
locally and it will work with GCC-like compilers.
That's a more robust way to call it as there is no CMAKE_C_PREPROCESSOR
standard value in any CMake file.
Nobody should call "cpp" manually anymore, but use the compiler driver
instead to do it for you.
That's why there's no standard CPP variable in CMake, it's not needed at
all.
For the same reasons, you rarely have to call the linker directly, it's
usually done through the compiler driver.
Calling it directly is kind of dangerous though since you will
probably be missing the proper language information and other options
that might affect the predefined preprocessor defines.
I'm not calling it directly, it was used by `configure` script of 3rd party.
gcc has different binaries for different target archs and has some
defines baked in, but this won't apply to Clang that uses only one
binary and a target triple.
For clang based android toolchain the CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX
variable points to the directory with gcc, so it will find `cpp`
preprocessor too. I don't know if it's good or bad :)
I think that's an implementation detail you shouldn't rely on. The
compilers in the NDK are changing, GCC is deprecated and you shouldn't
expect that.
Clang is mostly self contained and using very little from the GCC
distribution (binutils), it will be gone at some point, so you should be
ready for the future.
If you're updating CMake and changing the toolchain file, then I would
expect that some work has to be done, including making changes to the
invocation of a 3rd party script that is using custom variables from the
old toolchain.
Overall, I consider that taka-no-me Android toolchain to be tech debt.
It hasn't been updated for a long time, doesn't work with recent NDK
(unless you resort to use a standalone toolchain), locks people with
some custom variables making them believe they are standard and has tons
of other small bugs and issues.
I understand its appeal for most people, but to me, it has caused more
trouble than help. It could have been done so much better.
/Florent
--
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-developers
