[cmake-developers] Modern cross-platform buildsystem design requirements

[Stephen Kelly]

Brad King wrote:

> On 09/10/2014 11:49 AM, Stephen Kelly wrote:
>>  target_link_libraries(mylib cmake::android-16)
> 
> Interesting idea.  These could be predefined in the Platform/Android.cmake
> module.  However, I do not think the current ANDROID_API property will be
> outdated by such a design

Indeed. However, validation of allowed values might be worthwhile even now.

>>  macro(set_properties_for_platform tgt)
>>    if (CROSS_COMPILING)
>>      if (ANDROID)
>>        set_property(TARGET ${tgt} ...)
>>      elseif (BLACKBERRY)
>>        set_property(TARGET ${tgt} ...)
>>      elseif (WinRT)
>>        set_property(TARGET ${tgt} ...)
>>      endif()
>>    endif()
>>  endmacro()
> 
> I don't see any reason the properties could not just always be set by
> the project.  The ones not relevant to the current cross-compiling
> target would simply be ignored.

Right. That's probably true in most cases. Relatedly, I can imagine a macro 
like the above experiencing scope-creep though, which is a reason to not 
want to need it :).

> I think even your "toolchain scope" approach would end
> up being used in practice to wrap the entire CMakeLists.txt file.
> 
> The only approach I can think of that solves this without being a
> complete rewrite is to support multiple separate configuration
> passes, with separate CMakeCache.txt and everything as now, but that
> all feed in to a single generation step.  (Note the separate config
> passes could be independent and perhaps run in threads.)

Interesting idea. I'm not certain the resulting CMakeLists files would look 
much different to the "toolchain scope" approach though. You would still 
need conditionals with your approach:

 if(CONFIG_PASS_HOST)
   # CMake could set CONFIG_PASS_HOST in the normal case to avoid 
   # the need to check if we are cross-compiling
   add_executable(host_tool main.cpp)
 endif()

 add_library(mylib foo.cpp)
 
 if(CONFIG_PASS_ARMv7)
   # Add extra source for the config pass named ARMv7
   target_sources(mylib PRIVATE foo_embedded.cpp)
 endif()

But what is cleaner with your approach is that a find_package could be 
outside of any conditional if needed in all configuration passes.

>> When you refer to 'a new language' here, do you mean in the same sense of
>> how generator expressions were a new language (without a departure from
>> the current cmake language as a whole), or do you mean something
>> different?
> 
> I don't mean anything in particular except that we should not constrain
> ourselves to solving the problem with the current CMake language only.

Ok. When you wrote 

> However, perhaps it would be better
> in the long run to consider something more declarative and with a
> new language.

I thought you might have had something more-concrete in mind.

Thanks,

Steve.