Subfolder Concept

[thinkyhead]

See https://github.com/MarlinFirmware/Marlin/tree/breakup-marlin-idea/Marlin

[fabtopia]

Is it also posible to name the marlin.ino file to the branch name? So Marlin-RC.ino and Marlin-RCBugFix etc or even better Marlin-RC6, Marlin-RC7. When switching from RC6 to RC7 and the RCBugFix i have 3 "identical" looking marlin file in my recent files and in the titlebar of Arduino.

[Roxy-3D]

This needs to be done! There might be some debate about what the 'correct' organization is. For example, it might be better to name the UltraLCD folder as LCD_Panels and then have sub-folders in there for each display. But for sure, any organization is better than what we have now.

I expect there will be some debate about the names of the folders too. 'Base' doesn't seem right. Maybe something like 'Support'. And hopefully we will need a Folder titled 'HAL' soon! :)

After more thought: With the current file set you can't really do this. But a folder titled 'Bed_Leveling' might make sense. In my case, I would but G29, M48, G26, and G25 in there along with QR_Solve.* and Vector_3.* In my case, I think I can make QR_Solve and Vector_3 go away. So that wipes out half of the Base folder.

And I think it can be argued there should be a folder titled: Probing. Once again, that is difficult to do with the current file set. But it would be good to put anything that does probing in its own area (or module).

[Blue-Marlin]

• base sounds to(o) important to me. utility? tools?
• fonts can be a subfolder in ultalcd
• ultralcd should be renamed to lcd
• pull out language.h from language. Then move language to lcd.
• pins is one part of a hardware abstraction layer. fastio.h is part of a deeper hardware abstraction layer. The same level as interrupts, timers, adc, pwm, ...
• The borderline between core an module seems to be not very sharp. I would see scheduling, queueing input, parsing, ... and maybe planning and the stepper interrupt in core. An other category is hardware abstractions like extruders, steppers, heaters, endstops, probes, thermometers, SPI, I2C, serial, ... . Kinematics, bed leveling, PID, clipping, ... are more or less pure software concepts - not related to a special hardware.

[Roxy-3D]

base sounds to(o) important to me. utility? tools?

Support?

fonts can be a subfolder in ultalcd ultralcd should be renamed to lcd pull out language.h from language. Then move language to lcd.

Agreed.

pins is one part of a hardware abstraction layer. fastio.h is part of a deeper hardware abstraction layer. The same level as interrupts, timers, adc, pwm, ...

Good point. And maybe it makes sense to put them into a HAL folder?

But really.... for a first attempt... This is really good!

[thinkyhead]

You'll note the rampant abuse of #include and ".h" file suffixes. Purists of C++ architecture will consider this regressive. But for me it gas a certain charm - in great part because it can be done with a rusty knife and quickly, whereas truly dividing things up into functional units at the language level takes a lot more effort. In fact, any of the .h files can be split out into a separate .cpp file to make a new compilation unit, or new .cpp files can be added that group some .h files (only including their specific dependencies, as further split out from Marlin.cpp). Thus, as brute-force and crude an approach it appears at first, there be some madness method in it for eventually deriving true functional units.

[thinkyhead]

base sounds to(o) important to me. utility? tools?

I guess 'util' is customary.

[Roxy-3D]

I can live with 'util' ! The problem with 'base' is it kind of makes it sound like everything is built on top of it.

[jbrazio]

Having code (i)n header files has the side effect of inlining every function, even the ones without the [now surplus] inline keyword. I hope this is what you want @thinkyhead (I find it inelegant butchery). Having said that I like the overall concept. :+1:

About the "font" folder, I was preparing it's move to the buildroot (https://github.com/jbrazio/Marlin/tree/buildroot-cleanup) because it has no direct effect on Marlin, they are only complementary files. I haven't submitted yet this PR because I'm finishing the complimentary marlinfw.org doc about it.

[thinkyhead]

inelegant butchery

Yes, that's what I was going for. I wanted the essence of Marlin_main.cpp to remain unchanged, yet reduce the length of the file by a few thousand lines.

[thinkyhead]

the "font" folder, I was preparing it's move to the buildroot

That's fine too. The folder named 'lcd/dogm' now was named 'lcd/fonts' previously, with the bitmaps file outside of it.

[birkett]

Perhaps a 'boards' folder, which contains sub-folders for each supported board - i.e. boards/k8400/Configuration.h boards/k8400/Pins_K8400.h boards/makibot/Configuration_adv.h

[Roxy-3D]

Yeah. I think I agree. Right now there is a 'Pins' folder. And from the software's perspective that is what it cares about. But from the user's perspective, they have a 'Board'.

[thinkyhead]

From a developer point-of-view, I find it most convenient to have all the pins in the same folder. And we never intended to have a config example corresponding to every board (nor do we want to maintain them). The example_configurations have been maintained by each vendor.

[jbrazio]

I just don't like to have "core" files mixed with "config" files. I would suggest to have a config folder only with the config files the user can mess with.

[Roxy-3D]

From a developer point-of-view, I find it most convenient to have all the pins in the same folder.

I don't like flip flopping. But the fact of the matter is we want the code organized so the developers can find their way around in it. Pins is OK. I'll be quiet now! :)

[thinkyhead]

@jbrazio I moved most "core" items into "module" for a start. The "module" folder is still a catch-all and can perhaps be organized a bit more. I moved the non-editable items in "config" to a folder named "inc" lacking a better name.

[MagoKimbra]

Hi @thinkyhead... In the new version of the Arduino IDE 1.6.10 the folder which contains the files and other subfolders should be called 'src' Now the new location of the files must be: src/config src/core src/gcode etc etc..

I have had problems with the change from 1.6.9 to 1.6.10 because they were in the 'module' folder.

[thinkyhead]

@MagoKimbra Does that include src/Marlin.cpp too? Is it just because the name modules is used by the IDE for other things?

[MagoKimbra]

No no.. If you want use a subfolder the first name must is src.

src(folder) Marlin.cpp Marlin.h Marlin.ino

In src you can put any file and another subfolder src/module src/gcode src/pins src/core src/hal src/configuration.h src/configuration_adv.h etc etc

[thinkyhead]

How strange. It seems to me that forcing us to use "src" in newer versions of Arduino IDE is a regression. Is this intentional?

[MagoKimbra]

https://github.com/arduino/Arduino/issues/5176

I think yes!!!

[ghost]

It looks like that the "src" limitation has been eliminated just now. Do not limit includes to the src sketch subdirectory · arduino/arduino-builder@9d7d1d7 https://github.com/arduino/arduino-builder/commit/9d7d1d7cb95c12e73e9dd44df132a643089c3f40

Subfolders no longer compiled · Issue #5186 · arduino/Arduino https://github.com/arduino/Arduino/issues/5186#issuecomment-237254144

[bobc]

The issue that has been fixed relates to include files, they can now be in any folder below the top level. Other source files (.cpp etc) must in top level folder or in "src" subtree.

[thinkyhead]

Note to self on keeping this up-to-date…

1. Check out the latest code from RCBugFix
2. Rearrange sources in the same manner
3. Apply a diff between this branch and rearranged RCBugFix
4. Cherry-pick changes to keep, "discard" others
5. Do a separate diff of current Marlin_main.cpp with previous
6. Hand-copy changes to GCode handlers to each GCode handler file
7. Done!

[Wurstnase]

Teacup has a tool for this. https://github.com/Traumflug/Teacup_Firmware/blob/master/tools/git-step-rebase

Pretty simple. In the end you need a force pull/push of that breakup-marlin-idea. Just add that tool into your folder. Maybe you want to add this file to .gitignore

Then simple do:

git checkout RC or RCBugFix
git pull
git checkout breakup-marlin-idea
git-step-rebase RCBugFix

When the script stops, solve the issue and

git rebase --continue

When all issues are solved start again:

git-step-rebase RCBugFix

until you are done.

[eliasrm87]

Hi all,

What happened with this idea, is there any plan for getting this new tree structure into the main project? I truly think this is a big improvement, I'm available for helping on this task, if you need help let me know.

Regards

[thinkyhead]

Thanks for inquiring! This is a version 1.2 milestone. Version 1.1 is about to be released.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.