Open MrJake222 opened 12 months ago
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.
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.
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
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'sCMakeLists.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?
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.
👎 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...
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.
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: