building STM32 with CMake

[massonal]

and just to share I'm using python's 'virtual env' currently
https://docs.python.org/3/library/venv.html
https://realpython.com/python-virtual-e ... -a-primer/

I concur: virtualenv is, in my opinion, the way to go when you have several Python installation side-by-side (I think I mention it in the wiki; if not, I should ). I didn't (have to) use it with a Windows, yet, but I think it works there as well.

In addition, I even use virtualenvwrapper; that lets you simply run

Code: Select all

workon custom_arduino_env

instead of

Code: Select all

source /path/to/new/virtualenv/bin/activate

I think it is correct to say that the recent CMake versions has matured to address shortfalls for features that are missing in the past, e.g. recursive wildcard directory globs. It is there in some 3.x versions, but not earlier. That'd be necessary and likely used in our context.
This could help in situations where there isn't a 'CMakeList.txt' that commonly defines a cmake 'library' or module (in fact, it is recommended for individual directories). But, the reality "libraries" is in the wild aren't made up with CMakeList.txt, and wildcard pattern globing and recursion are about the means to include entire directory trees / sub-trees in the build.

I agree that globbing is convenient, to say the least (they even mention it in the Migration guide),
but it's still officially discouraged (see the doc on the `file()` command). This article explains it well:

... given that the CMake maintainers are so explicit about not globbing, I strongly believe the best thing to do is to list source files explicitly. In general, it is a good idea to avoid doing things that are explicitly unsupported because when you run into problems, the maintainers will simply tell you to fix your code.

Besides, manually listing source files is typically only annoying at the start of a new project, when the code structure is much more fluid. In the steady state, file lists change only occasionally, and the pain of updating a file list is not very great.

[ag123]

wildcard glob matches and recursion will be necessary in this 'arduinoish' and even possibly other lands as many of the code libraries and projects won't have a CMakeList.txt. This is particularly true for '3rd party' libraries, and even sketches. e.g. for that matter marlin firmware which may have hundreds of c++ or c files. making a CMakeList.txt for even any of such "projects" or "libraries" would be a pain if every .c, .cpp dependency needs to be specified in a CMakeList.txt and worse if they consists of hierarchy of folders, quite common for any moderately largish projects.

as it will not be possible to tell ahead how those "libraries" would structure their sub folders, wildcard glob patterns for "*.c" "*.cpp" "*.c++" and maybe even "*.ino" would likely be needed for 'external' libraries. without which there is no way to easily integrate them as dependencies in a generic way.

this is that trick that I managed with a 1 makefile build for all my sketches. When I need a new project, I simply copy the makefile and make adaptations.

edit:
i think the tone is a little overboard, well, they can be 'examples' if in case, 'external' libraries are needed, e.g. ref to those mastering cmake, migrations etc section should be adequate. it is likely this conundrum would be encountered when more people start using cmake for the builds, as practically this is a thing that could be frequently encountered with "external" libraries etc.

[massonal]

wildcard glob matches and recursion will be necessary in this 'arduinoish' and even possibly other lands as many of the code libraries and projects won't have a CMakeList.txt. This is particularly true for '3rd party' libraries, and even sketches. e.g. for that matter marlin firmware which may have hundreds of c++ or c files. making a CMakeList.txt for even any of such "projects" or "libraries" would be a pain if every .c, .cpp dependency needs to be specified in a CMakeList.txt and worse if they consists of hierarchy of folders, quite common for any moderately largish projects.

as it will not be possible to tell ahead how those "libraries" would structure their sub folders, wildcard glob patterns for "*.c" "*.cpp" "*.c++" and maybe even "*.ino" would likely be needed for 'external' libraries. without which there is no way to easily integrate them as dependencies in a generic way.

this is that trick that I managed with a 1 makefile build for all my sketches. When I need a new project, I simply copy the makefile and make adaptations.

edit:
i think the tone is a little overboard, well, they can be 'examples' if in case, 'external' libraries are needed, e.g. ref to those mastering cmake, migrations etc section should be adequate. it is likely this conundrum would be encountered when more people start using cmake for the builds, as practically this is a thing that could be frequently encountered with "external" libraries etc.

While I agree with you in the general case (to support arbitrary project structures you almost need globbing), in the particular case of Arduino I don't think it applies.
Arduino libraries are highly structured (library.properties at the root, all the code in /src), so globbing is not necessary.
In addition, it's not even sufficient, since some libraries embed precompiled binaries that complete / replace the source code, depending on the board (spec here). Hence the library has to be properly parsed, and a CMakeLists.txt generated to make the decision whether or not to build the source files. So why not do things right directly and make the generation script list source files?

Now, for other parts of the project, like the core or the variant, globbing might have been a good tool. It's not the way I have done it, but it could have been, and it's always open to discussion.

In a nutshell, my view on globbing is that it's an useful shortcut when you want to avoid the tedious work of listing the files (or straight away can't). But in my case, since the generator script is needed anyway, the compromise "easy vs right" does not apply any more.

[jancotipsarevic]

Hi all, this is an excellent initiative, to be honest it is the real reason I am here, I gave a try to stm32duino in the past but I gave up because I found tools too weak for serious programming. I have tried the CMake solution and I am really impressed, in spite of being a cmake beginner. I could say it is a truly a game changer, I am starting to adopt this framework for a hardware test and tool development infrastructure in my company. The development tool set I am using is stm32duino + cmake + CLion + OpenOCD so far with a very good performance. It is true CLion is a paid IDE but by just 100€ you have a perpetual license for the best C/C++ in the world (considered by many experienced developers), CLion provides flash and debug by the way, no CMake configuration is needed, by its integrated openOCD support.
Anyway I see you commented this is implemented “All the feature switches present in the Arduino IDE (and more!)” but to me it is no obvious how, I find no way so far to use the switches USB support, Optimize, C Runtime Library to be able to float printf , to use SerialUSB etc. I would be really pleased if you could provide any hint on how to declare them in CMake.
Thank you very much for this excellent work.