cmake: Use CMake targets #6872

flagarde · 2024-08-31T23:11:02Z

This PR generalise the use of targets. One of the goal is to allow libgit2 to be included upstream using FetchContent mechanism and to better express target dependencies.

Up to now libgit2 use variables to populate header path and libraries to the targets like :

set(LIBGIT2_INCLUDES ${LIBGIT2_INCLUDES} PARENT_SCOPE)
set(LIBGIT2_OBJECTS ${LIBGIT2_OBJECTS} PARENT_SCOPE)
set(LIBGIT2_DEPENDENCY_INCLUDES ${LIBGIT2_DEPENDENCY_INCLUDES} PARENT_SCOPE)
set(LIBGIT2_DEPENDENCY_OBJECTS ${LIBGIT2_DEPENDENCY_OBJECTS} PARENT_SCOPE)
set(LIBGIT2_SYSTEM_INCLUDES ${LIBGIT2_SYSTEM_INCLUDES} PARENT_SCOPE)
set(LIBGIT2_SYSTEM_LIBS ${LIBGIT2_SYSTEM_LIBS} PARENT_SCOPE)

using INTERFACE targets for external dependencies allow to wrap these informations. This is the favorite methode for post CMake 3.0 and allow better encapsulation.

For this to work (especially in CMake ~< 3.13), libraries in libgit2 should be STATIC or SHARED. The use of OBJECT is discouraged even by CMake developpers https://discourse.cmake.org/t/project-modularization-using-object-libraries/3825/5 and it seems libgit2 don't need their use.

This PR compiles and passes the tests but a second one would be necessary to polish and clean some useless variables not needed anymore

ethomson

Thanks for putting this together. cmake is not exactly my forte, but I think that directionally, this probably makes sense. I had a few stylistic questions:

This moves us from using globs / wildcards to match always to usually not using globs. Why (or when) is explicitly listing the source files preferred?

It seems like we're needing to specify more of the libraries than I would have expected. I don't understand it yet.

deps/ntlmclient/util.h

ethomson · 2024-09-27T09:20:30Z

deps/xdiff/CMakeLists.txt

-list(SORT SRC_XDIFF)
-
-add_library(xdiff OBJECT ${SRC_XDIFF})
+add_library(xdiff STATIC


Why is this preferable to just using a glob?

CMake recommands to avoid GLOB especially with source files :

https://cmake.org/cmake/help/latest/command/file.html#glob
``
Note

We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.
``

I made the changes in some places when I had to modify a lot the CMake logic. However it should be possiblle to supress all the GLOBs. This is quite easy and could be finish in an other dedicated PR.

deps/zlib/CMakeLists.txt

ethomson · 2024-09-27T09:21:59Z

src/CMakeLists.txt

@@ -157,11 +159,9 @@ endif()

 if(USE_THREADS)
 	if(NOT WIN32)
+		set(THREADS_PREFER_PTHREAD_FLAG TRUE)


TODO: what is this?

CMake advices to use set this variable to TRUE :

https://cmake.org/cmake/help/latest/module/FindThreads.html

To be honnest I don't know why adding the flag -pthread is better but it seems encouraged by CMake.

ethomson · 2024-09-27T09:27:34Z

src/util/CMakeLists.txt

@@ -1,20 +1,89 @@
 # util: a shared library for common utility functions for libgit2 projects
+configure_file(git2_features.h.in git2_features.h)
+
+add_library(util STATIC


Same question here - why is this preferred over a glob?

cmake/SelectXdiff.cmake

ethomson · 2024-09-27T09:44:25Z

deps/pcre/CMakeLists.txt


+if(MSVC)
+  target_compile_definitions(libgit2_pcre PRIVATE _CRT_SECURE_NO_DEPRECATE _CRT_SECURE_NO_WARNINGS)


Inconsistent indentation here...

src/cli/CMakeLists.txt

ethomson · 2024-09-27T09:54:29Z

src/libgit2/CMakeLists.txt

+	transports/*.c transports/*.h)
+list(SORT SRC_GIT2)
+
+add_library(libgit2 STATIC ${SRC_GIT2})


This was a bit confusing when we had an object library called libgit2, but (I think) it was only referenced as "$<TARGET_OBJECTS:libgit2>" so it wasn't so bad... now (I think) we are doing things like target_link_libraries(... libgit2). But that libgit2 refers (I think) to this libgit2, not the actual... libgit2. 🫤

Also, this produces a liblibgit2.a on disk which is not very attractive. Even if it is an intermediate step that consumers don't see, I think that we can improve this.

git2common or something? idk, maybe you have a better idea here.

If I understand correclty a shared library canot be used for some reason. If so if user wants a shared library libgit2.so we could compile shared and static (with name libgit2_static) and link specificly wiith the later and install the former. If user wants only static then libgit2.a could be used for both uses. I guess this could be solve in an other PR ?

ethomson · 2024-09-27T09:57:46Z

src/libgit2/CMakeLists.txt

-add_library(libgit2 OBJECT)
-set_target_properties(libgit2 PROPERTIES C_STANDARD 90)
-set_target_properties(libgit2 PROPERTIES C_EXTENSIONS OFF)
+file(GLOB SRC_GIT2 *.c *.h


Why glob here?

this GLOB should dissappear (cf. previous comments)

ethomson · 2024-09-30T19:51:48Z

Hi @flagarde - thanks for the details (and for your patience with my limited understanding of cmake, and my hurried PR review, where I still left TODO comments for myself 😢

I am excited about improving our cmake configuration, so I'll 👀 this soon. 🙏

flagarde added 30 commits September 1, 2024 01:46

targets

25d0672

fix

67013a3

STATIC

4d20a56

Static

643df93

targets

45a87db

add target

0f35e68

fix

39a0221

fix

46d0048

fix

f63e2dc

pcre

b5ef124

fix

bd2c19b

pcre

ca83053

fix

c125a6b

fix

004c876

fix

0f03e94

fix

8d9a386

zlib

9b41a95

fix

fdd2e42

fix

45e0a0b

fix

a19037d

pcre.h

efab868

fix

c1a7bc3

fix

f8fc547

fix

a46cb81

gss

54af8ff

fix

16325cc

fix

ad5a331

fix

3ba2ebc

fix

ddea2e1

fix

6f95b5a

flagarde added 2 commits September 1, 2024 06:34

ssh2

c1dfcfe

Update FindPCRE.cmake

207c109

ethomson reviewed Sep 27, 2024

View reviewed changes

flagarde mentioned this pull request Sep 28, 2024

Add headers ethomson/ntlmclient#25

Merged

flagarde added 11 commits September 29, 2024 01:07

Update CMakeLists.txt

022c3a6

Update SelectGSSAPI.cmake

182e83a

Update SelectHTTPParser.cmake

df2b4ac

Update SelectHTTPSBackend.cmake

64934c3

Update SelectRegex.cmake

5688ccc

Update SelectXdiff.cmake

bf9e772

Update CMakeLists.txt

af507f9

Update CMakeLists.txt

2a5e3c0

Update CMakeLists.txt

1cbf378

Merge branch 'main' into target

d82c11c

Update util.h

f836120

ethomson mentioned this pull request Dec 23, 2024

cmake: remove globs #6977

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

cmake: Use CMake targets #6872

cmake: Use CMake targets #6872

Uh oh!

flagarde commented Aug 31, 2024

Uh oh!

ethomson left a comment

Uh oh!

Uh oh!

ethomson Sep 27, 2024

Uh oh!

flagarde Sep 27, 2024

Uh oh!

Uh oh!

ethomson Sep 27, 2024

Uh oh!

flagarde Sep 27, 2024

Uh oh!

ethomson Sep 27, 2024

Uh oh!

Uh oh!

ethomson Sep 27, 2024

Uh oh!

Uh oh!

ethomson Sep 27, 2024

Uh oh!

flagarde Sep 28, 2024

Uh oh!

ethomson Sep 27, 2024

Uh oh!

flagarde Sep 27, 2024

Uh oh!

ethomson commented Sep 30, 2024

Uh oh!

Uh oh!


		if(MSVC)
		target_compile_definitions(libgit2_pcre PRIVATE _CRT_SECURE_NO_DEPRECATE _CRT_SECURE_NO_WARNINGS)

cmake: Use CMake targets #6872

Are you sure you want to change the base?

cmake: Use CMake targets #6872

Uh oh!

Conversation

flagarde commented Aug 31, 2024

Uh oh!

ethomson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ethomson commented Sep 30, 2024

Uh oh!

Uh oh!