-
Notifications
You must be signed in to change notification settings - Fork 130
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
Changing board configuration leaves behind unnecessary files, even after "lbuild clean" #285
Comments
The DISCO-F469NI board in particular pulls in a lot of modules, because it uses a lot more hardware than the DISCO-F429ZI. And thus the file diff you see is quite a lot. (There's also the
Vigerously delete the generated |
That seems like a strange design to me. With most build tools, running It sounds to me like you're trying to support a scenario in which the user is modifying files within the build output tree, but I don't understand that use case yet.
That is a solution I can confirm works 😁 But doesn't it seem odd that the user has to do that to truly clean the build output? |
Perhaps stated differently: as far as I can tell, |
That's exactly right. Once you've settled on a reasonable configuration, the clean generated code should be committed into your repo and then the required changes can be tracked in another commit. When you want to upgrade modm, you can diff the changes in the generated files, as well as re-applying the patches you made. This allows to upgrade long-running projects to the latest modm release with a reasonable effort (I need to actually create a release with changelog again for this to work tho -> #44). |
The user may also have to clean up the build systems (scons) build path manually.
A tooling for actually utilized use cases would be nice! |
How many users does this actually affect? |
Everyone at the DLR, aka. the people that lbuild was originally designed for 😉. Although they use the OUTPOST repo not modm, but same issues. |
Ah, interesting! I suppose my mindset is wrong then. I keep trying to imagine modm as a library but it's truly designed as a generator for HAL code which you then adopt into your project as a peer. It seems foreign to be to bring in an external module and then modify the code it generates, but I suppose there are use cases for that. In that case, are there any available projects which you can point me to which consume modm as an external party? e.g., a GitHub repo where someone added a modm submodule, configured a project, checked in the generated output, and added code which uses it? That would be very helpful as a reference for the expected structure of my own project. Thanks for all the quick responses! |
Yeah, Niklas, just do it right from the beginning!1!! Why couldn't you have forseen all the problems beforehand?2?? Are you even a real programmer??? 😉 I know, no, I feel these issues too, I've been refactoring this stuff for the last 5 years…
Yeah, that's cos it isn't well documented either. The constant code committing is annoying with a very dynamic project that changes a lot or even modifies modm itself a lot. The @roboterclubaachen is/was the main user of modm and lbuild didn't integrate very well into the existing workflow. (we didn't commit any generated code there either). It's difficult to solve these things particularly without getting inspiration from other projects, however, there aren't a lot (any?) projects that use code generation so extensively. All projects that do use some code generation, commit their generated code into their own repo, that's of course not possible with modm.
Nothing public, sorry! The invensense repo uses modm (via |
Also keep in mind, that lbuild doesn't deal with dependencies on a file level, like actual build tools do, only at a module level. We don't want to write a build tool, since they already exist (hence the |
One project where I did commit code was the ELVA project, but I cannot upgrade that since we're still using C++14 for that code, and modm is using a few C++17 features very, very extensively (specifically |
Regarding upgrading use-cases: roboterclubaachen/xpcc#160 |
Some backstory: I myself am on a competitive robotics team and we are looking into using modm for our main controller code. I really, really want to get it working and integrated with a reasonable development experience, and think it would dramatically improve our quality-of-life over the workflows and tools we currently use. The hardest part is just figuring out how to use it 😁 If I am able to get my team set up with modm and it works well for our use cases, I'd be happy to contribute some time to improving things as I go. Most of it would probably be documentation, but I'd also contribute code where I am competent enough to do so. While I'm going along and figuring things out, I'd really like to help improve this experience for future users. It was striking to me that this repo had only about 200 start despite having such an apparently clean API surface, and I think improving the docs and the "getting started" experience would help a lot with that. There are a lot of API usage examples (and that is excellent!) but:
Anyway, getting back to the main point of this issue (some of this is better-suited to #280), I think clarifying how lbuild and its output can be integrated into a user's codebase would go a long way to improving the setup experience. Heck, why not just create a Admittedly, it sounds like you aren't 100% sure on how modm is best integrated into other projects, making it hard to settle on a single suggestion to give to others. But if there is a specific setup that you think would work well (e.g., have modm as a submodule, commit the generated output to your repo, then upgrade modm intermittently), please do document it! And really, I am serious about having a template repo to start from; that would be extremely helpful. I would even be willing to make one if you tell me how you think it should be structured. And I can always set up my project, try it out for a bit, and give feedback on the experience. And speaking of all this, as you mentioned, somewhat consistent releases would be very helpful for signalling when people should upgrade. It seems a bit scary to work on a rather arbitrary commit, and have no single tag where users are actually testing. |
Sorry for the long rambling comment only tangentially related to the original issue 😆 |
Yes, I've been thinking about this ever since GitHub introduced template repositories some months ago. |
Started a template repo here: https://github.com/modm-io/modm-template |
GitHub Developer Support answer came back:
Hm, well… why did you even ship this feature? |
Alternatively we can also commit normally onto the develop branch of the template repo and have a CI job squash the commits and force push them into the master branch, and then people can clone it normally. Or we just wait until GitHub fixes this issue, and until then people just have to deal without repo history. Meh. |
Hmph, that's frustrating. What's the scenario you want to support -- maintaining history of the repo template? Or avoiding history of the repo template? |
I'll just ignore the template feature for now, and just make people fork it. That means, they'll have the full history of it. If it's less than a year or two until they fix it, the history won't be that large anyways. |
Say I have a project which extends
modm:disco-f469ni
. Note that it has a significant number of files, some of which aren't included by other targets. Now, I change my project to instead extendmodm:disco-f429zi
. I runlbuild clean
(optional) andlbuild build
again. While the core board source files have been updated, theREADME.md
and miscellaneous support files from the other board were left behind.The output from
lbuild clean
:It seems strange to me in general that
lbuild
never seems to remove many of the files in the build tree. I have a diff here which shows the changes made bylbuild clean
. What am I missing? Doeslbuild
only remove particular files, e.g. files that were generated via template?While the left-over files might have technical ramifications if you are using a custom build configuration, for me this caused a bit of confusion when I was trying to make a custom board configuration. I had originally intended to copy the files from the GitHub repo, but this document suggested copying them out of the build tree after running it through
lbuild
. If I did so after changing my board configuration I'd be left with extra files that weren't needed and said they were for a different board.The text was updated successfully, but these errors were encountered: