add_library, sources as list not producing DLL, no error either

Hi,

I’m trying to write a CMakeLists.txt file in VS Code using the Microsoft C compiler to make a DLL target. I never learned ‘make’ files the hard way so you may need to explain me some dumb. But I did get my whole process to run in command line (without CMake) and produce the DLL I want. I would just prefer to learn the VSCode / CMake method so I can grow things later.

For my project I want to use a list of source files in the add_library() command. But I can’t get the list to work in both of two different ways. I only seem to be able to make add_library() work with the sources hard-coded in that call. I know about the wisdom of not having target source lists that can change in a CMakeLists.txt file and I have a grasp of that issue I think as you might tell below. I want to be able to use a list for just ease of management / edits.

The DLL created will be used by an .EXE from some vendor. The vendor gives a library to link against a header file to use each time in my own C source files.

For the CMakeLists.txt, when I hard-code my source file paths in add_library (separated by spaces) and then Build the project with the corresponding .vcxproj, I get the DLL and it works as mentioned. I am keeping the vendor library and header file in the vendor folder - NOT at my project folder (is this a problem???) - but, like I said, it works with add_library() and the sources hard-coded.

Under all scenarios I can check the sources of the target. The returned value is a list and I can query those items and they match my input.

But when I use the list in the add_library() though a couple things happen. First is I get an error that CMake can’t figure out the linker language. I can solve this error by setting that property for the target. Second is that - although the BUILD runs without error stated - I GET NO DLL. Below is my two different setups. Can you tell what’s wrong? Do you need the whole file? I’m running CMake Version 3.27.4. Thank you.

Kirk Morgan

PS I am detecting that capitalization may play a role. How would I tell? My file names were capitalized in Windows OS at draft time of this note.

PPS Can someone please confirm my request for discourse account was received and e-mail sent to my mail account? I tried this account and my gmail but the confirm invitations don’t come through. Thank you.

this (which Build ‘without error’ won’t give a DLL)

file(GLOB SOURCES CONFIGURE_DEPENDS "*.C")
add_library(userpack SHARED ${SOURCES})
set_target_properties(userpack PROPERTIES LINKER_LANGUAGE C)

nor these (which also Build ‘without error’ but won’t give a DLL either)

# variant 1/2
list(APPEND SOURCES ${CMAKE_SOURCE_DIR}/REALSUM.C ${CMAKE_SOURCE_DIR}/TRNSPOSE.C ${CMAKE_SOURCE_DIR}/USERPACK.C)
# variant 2/2
list(APPEND SOURCES REALSUM.C TRNSPOSE.C USERPACK.C)

add_library(userpack SHARED ${SOURCES})
set_target_properties(userpack PROPERTIES LINKER_LANGUAGE C)

versus this (which works)

#Make the target and put the sources on it
add_library(userpack SHARED realsum.c trnspose.c userpack.c )

This tends to mean that CMake didn’t recognize any compilable sources in the target for which to compute it on its own.

I suspect the problem here is that you have .C extensions which is, by default, indicative of C++ sources. Given that C++ is enabled by default, I think you have project(userpack LANGUAGES C) and only enable C and therefore disabling C++. These .C files then get classified as C++ and, without C++ support, are not compilable.

You can keep the names and do something like this:

set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE C)

to override the automatic detection and force them to be considered C files.