Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake usage in recommended project structure #1098

Open
jensboe opened this issue Nov 5, 2023 · 3 comments
Open

CMake usage in recommended project structure #1098

jensboe opened this issue Nov 5, 2023 · 3 comments

Comments

@jensboe
Copy link
Contributor

jensboe commented Nov 5, 2023

If I read https://modm.io/guide/custom-project/ correct it is intended to maintain multiple binaries in one repo (in example a dual core processor)

.
├── ext
│   └── modm
│       ├── repo.lb
│      ...
└── app
    ├── nice_project_1
    │  ├── main.cpp
    │  └── project.xml
    └── nice_project_2
        ├── main.cpp
        └── project.xml

Therefor for each project lbuild must be run and each got an modm folder.

Is this the intended way for modm?

In this configuration I normally have a CMakeLists.txt which includes "everything" and can build everything in root/build/ (root/build/app/nice_project_1 , root/build/app/nice_project_2 and so on). With only to commands I can build every target. No directory switching needed.

If I try to do it with an modm_project, I got some errors because the pathes doesn't match because wrong variables are used at some places.

I could fix it easily and can create an PR.

Maybe https://github.com/modm-ext/modm_starter_project should be updated to match the recommended file structure of https://modm.io/guide/custom-project/

@jensboe
Copy link
Contributor Author

jensboe commented Nov 5, 2023

One problem while trying to fix/improve cmake:
I need to update the path of the linkerscript in LINKFLAGS
-Tmodm/link/linkerscript.ld should be -T${PROJECT_SOURCE_DIR}/modm/link/linkerscript.ld

But I am not a python or lbuild expert.
\modm\tools\build_script_generator\scons\module.lb set linkerscript path in build(env) function but if I try to copy that into cmake, it fails. the build function in modm\src\modm\platform\core\cortex\module.lb always "wins" (and got called before cmake-build.

I then try to use the override option of cortex-m
<option name="modm:platform:cortex-m:linkerscript.override">"${PROJECT_SOURCE_DIR}/modm/link/linkerscript.ld"</option> but if failes because lbuild wants to resolve the ${PROJECT_SOURCE_DIR} variable which doesn't exists because it's for CMake.

If I use a real relative path it works<option name="modm:platform:cortex-m:linkerscript.override">app/nice_project_1/modm/link/linkerscript.ld</option>.

@salkinium
Copy link
Member

It's intended to compile the projects separately. I'm not a CMake expert, there's too much conflicting advice online about how to do things in CMake that I never got how it's supposed to work, so I don't really know how good our solution is. Thank you for improving it!

What you're looking for is this flag_format function, that translates placeholder values in collected flags into the build system specific format.

The linkerscript flags gets added here. You can see that the -L{project_source_dir} flag gets translated to -L${CMAKE_SOURCE_DIR} via the flag_format function for CMake.

So you should get this behavior by replacing CMAKE_SOURCE_DIR with PROJECT_SOURCE_DIR in the flag_format function and everything else should work as you intended?

@salkinium
Copy link
Member

Did you find a solution to your problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants