CMakelists.txt not containing target include directories

[lefebvresam]

Development Machine, OS, Compiler (and Other Relevant Toolchain Info)

WSL2 on Windows10 education pro
Cross compiled for arm on Ubuntu 20.04

SDK Version (Please Give Commit SHA if Manually Compiling)

1.4.1

Describe the Bug

When linking the project in an existing cmake project, you have to add the include directories manually to enable finding the header files:

 # Create AZURE_IOT_SDK target
 set(AZURE_IOT_SDK "${CMAKE_CURRENT_LIST_DIR}/../../lib/azure-iot-sdk-c")
 add_subdirectory(${AZURE_IOT_SDK})  
 set(AZURE_ADD_INCLUDEDIRS "${AZURE_IOT_SDK}/deps/umock-c/inc"
                           "${AZURE_IOT_SDK}/iothub_client/inc"                         
                           "${AZURE_IOT_SDK}/c-utility/deps/azure-macro-utils-c/inc")
 target_include_directories(iothub_client INTERFACE ${AZURE_ADD_INCLUDEDIRS})

Normally the target_include_directories must be already in the top CMakelists.txt of the project.

[ewertons]

Hi @lefebvresam ,
could you paste the steps you took to install the azure-iot-sdk-c library in the environment?

If you would like, you could use our vcpkg port. Please see the following guide.

[lefebvresam]

These are the steps:

• Create a git submodule in your sub-project that points to the Azure SDK, the latest stable release: https://github.com/Azure/azure-iot-sdk-c.git and do a 'git submodule update --recursive'

• In your own sub-project, add the location to the package before running the well known cmake commands (cmake .. and make). CMakeLists.txt will be readout and the project will be attached. Due to a design flaw, add include directories manually:

# Create AZURE_IOT_SDK target 
set(AZURE_IOT_SDK ${CMAKE_CURRENT_LIST_DIR}/../../lib/azure-iot-sdk-c) 
add_subdirectory(${AZURE_IOT_SDK})   
set(AZURE_ADD_INCLUDEDIRS ${AZURE_IOT_SDK}/deps/umock-c/inc 
                          ${AZURE_IOT_SDK}/iothub_client/inc                        
                          ${AZURE_IOT_SDK}/c-utility/deps/azure-macro-utils-c/inc 
                          ${AZURE_IOT_SDK}/c-utility/inc) 
target_include_directories(iothub_client INTERFACE ${AZURE_ADD_INCLUDEDIRS}) 

• Use a module by adding the name in de CMakeLists.txt of the sub-project and additional include directories for the project:

  target_link_libraries(${PROJECT_NAME} PUBLIC ... PRIVATE iothub_client ... )

• Include files are now found in the path for the sub-project and can be used accordingly:
  #include "iothub_client.h"

• Compile the sub-propject with these options off: -Wall, -pedantic, -Werror to avoid compiler errors. The following modules become available:

[ 44%] Built target aziotsharedutil 
[ 50%] Built target umqtt 
[ 55%] Built target iothub_client_mqtt_ws_transport 
[ 55%] Built target parson 
[ 61%] Built target iothub_client_mqtt_transport 
[ 72%] Built target iothub_client_amqp_ws_transport 
[ 77%] Built target iothub_client_amqp_transport 
[ 83%] Built target iothub_client_http_transport 
[ 94%] Built target iothub_client 

• To compile for amd64 targets (eg in a docker), install libcurl4-openssl-dev and uuid-dev

• To compile the main project, add the include dirs to the main project path and add you sub-project module:

  target_include_directories(${PROJECT_NAME} PUBLIC ... ${AZURE_ADD_INCLUDEDIRS} ... PRIVATE ...

• Compile the main project also without compiler options -Wall, -pedantic, -Werror

Remarks:
1/ There is a lack on a good integration guide, also about the use and config of the cmake files
2/ Probably there is a design flaw for integration
3/ The project is not suited for compilation with strict compiler options which invokes problems for integration within existing projects.

[neonsoftware]

I just happen to have just tried to integrate the sdk as a module as @lefebvresam as agree that it is not possible to use it as a module due to missing target_include_directories, et al.

(@lefebvresam let me know if you agree with the following wrap-up)

Thank @ewertons for the link, I have just checked and it seems to me that I could summaries the difference between what it is possible and the proposed improvement:

• currently, as the proposed guide, the strategy is: download the sdk on a side, build it with cmake, install it manually on your machine, then the user on another separate Cmake project pick up the installed sdk (with find_package).
• proposed by @lefebvresam : the sdk is already a Cmake that fully integrate as package, the final user's project's Cmake points to the SDK location it on github, never install it anywhere, and only when the user builds its project, the sdk is downloaded and prepared behind the scenes, and depenencies automatic.

One example for this is Cmake FetchContent for googletest, other libraries supports it, and some reasonings towards this approach could be found in this article or this repo.

(it seems to me that was also proposed by #603 (comment))

The Cmake of this SDK seems already well organized, the effort forwards this future-proof addition is probably little.
What is your opinion ?

[lefebvresam]

I totally agree. The advantage by using the SDK as a GIT submodule is that you can refer to a specific revision in your GIT submodule dependency files and you can go trough the source code in your IDE. This is important when you have to copy macros or specific variables when you integrate the SDK into a C++ project, or you want to debug and add extra logging in the source.

[danewalton]

Hi @lefebvresam and @neonsoftware I agree we can make some improvements in our CMake. These were originally written years ago before the days of "Modern CMake" and haven't been updated with the times. I'll see if I can budget a bit of time to try and go through to enable the scenario y'all are talking about. Thanks for the feedback.

[neonsoftware]

Hi @danewalton,
Thank you joining in and looking into this aspect, much appreciating it !
Don't hesitate to keep in touch in the issue for any info/evolution,
Cheers, have a nice week.

[neonsoftware]

Just one last thing, @ewertons and @danewalton, in view of the exchange of informations in this issues, would it be possible, or appropriate, to move the issue's label 'question' to 'enhancement' ?
Cheers, have a nice week.

[danewalton]

Yup can do....relabeled

[neonsoftware]

Hi @danewalton and @ewertons ,

First of all, thank you for taking a look at this topic.

I have been using different azure libraries in the last month and have seen, scattered around the libraries, different CMake adjustments required.

I would like to ask you

• Is, within Microsoft, moving to seamless modern CMake within the objectives or roadmap ?
• In that case would it be an internal project or more a Github project/roadmap with pull requests and work needed ?
• Do you need further input from users to identify use cases and issues ?

Thanks.
Wishing a great day

[felix-kolbe]

I can confirm I also had had that problem back in 2021 and found a small workaround to be:

# Get the includes of Azure IOT SDK as it does not publish them within its library target
get_target_property(azureiot_includes iothub_client INCLUDE_DIRECTORIES)
target_include_directories(${TARGET} PUBLIC ${azureiot_includes})

But as of newer versions, at least with LTS_08_2023, this doesn't seem to be necessary anymore.