add basic support for cmake

[MrJake222]

A lot of projects (for ex. pico-sdk) use cmake as their compilation helper. I needed to include this in my Pico project, so here it is.

It becomes trivial to use (and also add compile flags). Example:

add_subdirectory(littlefs)
target_compile_definitions(littlefs PUBLIC LFS_THREADSAFE)

[geky-bot]

Tests passed ✓, Code: 16666 B (+0.0%), Stack: 1432 B (+0.0%), Structs: 788 B (+0.0%)

	Code	Stack	Structs		Coverage
Default	16666 B (+0.0%)	1432 B (+0.0%)	788 B (+0.0%)	Lines	2316/2496 lines (+0.0%)
Readonly	6126 B (+0.0%)	448 B (+0.0%)	788 B (+0.0%)	Branches	1184/1506 branches (-0.0%)
Threadsafe	17494 B (+0.0%)	1432 B (+0.0%)	796 B (+0.0%)		Benchmarks
Multiversion	16742 B (+0.0%)	1432 B (+0.0%)	792 B (+0.0%)	Readed	29369693876 B (+0.0%)
Migrate	18350 B (+0.0%)	1736 B (+0.0%)	792 B (+0.0%)	Proged	1482874766 B (+0.0%)
Error-asserts	17302 B (+0.0%)	1424 B (+0.0%)	788 B (+0.0%)	Erased	1568888832 B (+0.0%)

[geky]

Hi @MrJake222, thanks for creating a PR.

I appreciate the thought to upstream this, but I'm hesitant to bring this in unless more people weigh in that this is useful.

The problem is that there's always N+1 build systems, and my general experience is cmake configuration ends up very project-specific. Though those projects could have been using cmake "wrong".

---

We would probably also need to add cmake to the CI to at least test that the configuration continues to build correctly.

[zyglyf]

This would definately be usefull for us when integrtating littlefs into our CMake based projects. Having to add littlefs with ExternalProject_add() and setting a BUILD_COMMAND with a lot of parameters to get it into a CMake project is just not a good solution and is highly dependent of the format of the littlefs makefile.

[Oakchris1955]

Adding CMake support would be really helpful for those using CMake for their projects. On the other hand:

cmake configuration ends up very project-specific

I believe that it would be better just to create a section in the README describing which CMake commands to include in one's CMakeLists.txt in order to link the littlefs source files

[bmcdonnell-fb]

Adding CMake support would be really helpful for those using CMake for their projects.

Yes.

On the other hand:

cmake configuration ends up very project-specific

I believe that it would be better just to create a section in the README describing which CMake commands to include in one's CMakeLists.txt in order to link the littlefs source files

👎 What if the app developer wants to include the littlefs repo as a git submodule, and build it as a library with CMake?

[bmcdonnell-fb]

Shouldn't (or couldn't) this be PRIVATE?

[bmcdonnell-fb]

Indeed, I tested it as PRIVATE, and was able to build.

[jmalmari]

I'm a fan of CMake but would vote a no on this one. There is really only one compilation unit in the project. Two if you include the CRC implementation. Easy to add to any build system.

Those that want to add it as a library, could do so. Those that want to add it directly into their own target, could do so as well. Pleasing both use cases and who knows what else invites some maintenance work along the way.

Doing add_subdirectory() to include another project requires some careful thought. Do you really want the other project's install files, tests, benchmarks, development dependencies to be part of the parent project? Granted, that's not the case here since the project is not using cmake but that's generally what root level CMakeLists.txt is for. I'd rather see this in some support/static_library.cmake etc.

ExternalProject_Add() is a bit more isolated but still invokes the same unnecessary complexity in the subproject's own build system while actually you are only interested in a couple of files.

[geky]

👎 What if the app developer wants to include the littlefs repo as a git submodule, and build it as a library with CMake?

It sounds like a problem with the build system if it doesn't support this use case.

I'm a fan of CMake but would vote a no on this one. There is really only one compilation unit in the project. Two if you include the CRC implementation. Easy to add to any build system.

CMake supports globbing doesn't it? The relevant sources are *.h and *.c is this is unlikely to ever change.

---

It's interesting to note no other project in the space (dhara, spiffs, ChaN's fatfs) provide a CMakeLists.txt. ChaN's fatfs, the most popular, doesn't even provide a Makefile.

Worst case we could provide a separate repo, maybe littlefs-cmake, for CMake integration. But I think the CMakeLists.txt will never actually converge into something that makes everyone happy. I'm also not sure the maintainer-headache vs user-headache tradeoff makes sense...

[bmcdonnell-fb]

I'm not sure I'm entirely persuaded, but based on feedback here, I'm content not to keep advocating for this one.

I'm not the pull requestor, though.