Multiple projects side by side

[tago]

Hi,

how do you setup multiple projects?

Do you have a single mios32 installation and put your projects in folders outside of the mios32 folder?

I mean, if i setup mios/toolchain/global environment vars according to the wiki docs these vars are actually global. So i don't see how this would work for different mios apps which possibly need different env vars or mios versions.

Doesn't it make more sense to put a new mios installation into each project folder and get rid of the global vars to have the project's dependencies in its respective project folder?

 

Thank you

 

[TK.]

Hi,

actually environment variables are "local" in your shell. Which means, if you open multiple shells you can set the variables to different values in order to work on multiple projects in parallel. Build objects are created locally in your app folder as well.

Or you could create a small shell script which sets the variables before calling "make" - this way you could work from a single terminal.

Or you quickly switch between the setups by sourcing one of the "source_me_*" files in the base directory: https://github.com/midibox/mios32

Of course, it's also possible to create different GIT clones which makes sense if you work in separate branches for each activity.

Best Regards, Thorsten.

[tago]

Thanks Thorsten!

I'd like to further understand the structure and workflow of the repository.

My simplified view: it looks like /apps are the apps and everything else is the 'mios lib' (mios32/modules..). I'd like to know how do you handle changes to the 'mios lib' for all the apps? What if there are some breaking changes? Do you edit/refactor all apps every time this happens or is there some kind of a fixed API that never changes (or very seldom)? How often gets the mios stuff updated? I assume the apps are updated more frequently.

I'm trying to find an ideal setup for multiple midibox projects. To my modest knowledge it's the best to have each project's includes/dependencies separated from each other to avoid problems compiling them after some time later. In that scenario i'd pull 'mios lib' version updates on per project basis, not for all projects. But does it make sense or should i rather have a global 'mios lib'?

 

Edit: i only intend to work on app level.

Edited April 16, 2019 by tago

[Hawkeye]

@tago trying to free up time for TK a bit here, if what i am saying is wrong, he will surely correct me:

With libraries, the intention is to have more or less "stable" interfaces, that multiple apps can rely on. Defining the interface at first is why it is so difficult to create them :). You would need to define a  "minimal" (non over-engineered) interface at first and try to only extend it over time. If you need to change a core api function call signature, all dependencies have to be updated, that's why this should be avoided and i think this is excatly what Thorsten does.

So, from an "app implementors viewpoint", you'd only need to check out everything once, and work on the "app level", use the MIOS library as far as possible. If the library does not provide for what is needed, you can extend it internally within your app. If that extension results in a function that you think will be useful for other users, you could extend the library itself and create a pull request for Thorsten to evaluate your addition to his code. The idea is always to avoid overengineering, an API that is too vast is often distracting, complex to understand and will make development harder.

Hopefully this was correct and helpful!
Best regards,
Peter

[tago]

Thanks Peter!

Yes, it is helpful.

I understand it that way, that you recommend using a single mios32 installation as global lib. No need to put duplicates in each project folder, because the interface doesn't change often and mostly there are new functions added.

Hard to decide, i somehow lean towards a self contained per project solution.

[tago]

I've question regarding Git.

Say i want to edit the NG app which is (like all apps) part of the main mios32 repository. How would i keep track of changes to NG if i copied it out of the main repository into its own folder? There would be no git anymore.

[Hawkeye]

@tago it depends on your preferred workflow, personally i would not recommend to move anything at all outside of git, as you will lose the benefits of having an integrated code version control system, i.e. you could look at any time what you have modified locally and you can perform local commits that are not pushed back to the server while you work on your personal projects.

I'd see two options:

a) you could just work within your fully cloned repository tree

b) i have not done it, but it might be possible to clone the main tree (library) somewhere, point your environment variables to it, so the build process works and clone the respective app subdirectories somewhere else (if this works, i think i read about "sparse checkouts" somewhere). This would allow you to work more like you describe on an individual app/project level within a separate directory structure but with full git benefits, if you prefer that. If this does not work, you could just create logical filesystem links, if you are working in a unix environment?

With both variants you can perform local commits, which is useful for development.

If you work from multiple local machines like a laptop and a desktop you could also setup a server system like "gitea" and enable pushing to a central server by adding a new origin - that works nicely and you would then have a local tool like "github" at home, including browser based diffs and all the bells and whistles :).

Many greets and have fun!
Peter

[TK.]

The workflow can be much easier: just clone the worktree, create a branch, commit into this branch how often you want, push to GitHub whenever you want to ensure that your work doesn't get lost (and want that other people can access your changes).

There are various tools to display code changes between branches, between your commit, etc. also locally without the need for a webserver.
E.g. I'm using "gitk", but there might be many others.

But uploading to GitHub is preferred - not only for backup reasons, but also to allow later merging into master branch via pull request + review from my side.

Best Regards, Thorsten.