-
Notifications
You must be signed in to change notification settings - Fork 12
Conversation
… parts. They are still functions, not actual script parts as the initialization system is, yet each has its own file - Following SRP's design principle.
… 'Extras' directory. All 'Print' functions are located in the 'Printer' script, while the 'Debug' functions are located in the 'DebugOptions' script.
Updated project's authors and home page on GitHub.
All scripts are located under the 'Core/Libraries' directory, named as factories since they serve as a kind of factory methods. Renamed the functions to 'make_xxx' as a result.
…directory. Renamed all of the functions to 'create_xxx' since it's a better suited name, except for the 'Arguments' classes, which were renamed to 'build_xxx' since they are similar to a builder (Will be refactored to a one in the future).
Sketch setup is located under the 'Sketch' directory, along with 'ArduinoSketchToCppConverter' which has been moved as well. Example setup is located under the 'Examples' directory. Renamed all functions to 'make_xxx' since they are kind of factories.
Removed 'find_prototypes' function since it SEEMS it's no longer needed. Will return if I'm wrong...
The script, named 'Macros', is located under the 'Extras' directory and currently contains all existing macros. Also extracted the 'load_generator_settings' function to a script file named 'GeneratorSettingLoader', also located under the 'Extras' directory.
Bug was in generated makefiles - They had misplaced colons (:). Solution was to retain the previous state (before refactoring) where the hardcoded string setting the compiler flags was a single line. During the refactor process it has been line-broken for convenience.
First bug has yet again been at 'CompilerFlagsSetter', as the 'set_compiler_flags' function didn't accept a 'defined_version' as a parameter - crucial to a successful build. Solution was to get it from the 'is_sdk_version_valid' function, since it's defined there. Second bug has been in the definition of 'Recurse' libraries. During the refactoring process all 'library_RECURSE' definitions have been moved to the 'SetDefaults' script, but since they're not set as cache variables, they are redefined on each CMake reload, causing their value to become undefined. Current solution was to just move them back to the main 'Arduino' script.
This is done by checking whether a variable is defined at the beginning, setting it to 'True' at the end. This may have improved CMake's reset time by a few hundred milliseconds!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM refractoring-wise
Just a purely cosmetic request, could you add newlines to the end of the files ending in text? It's nothing functional, but common practice on unixoid systems and git is always chatty about it when diffing.
EDIT: Also before I forget, what do you think of having codestylesettings.xml in the repo? I'm usually against having IDE-related stuff there but it'd make collaborating easier as Alt+L won't reformat each others code on every occasion
@JonasProgrammer Sure, I thought I already added those, seems not 😆 |
It seems to solve some issues arising in Unix-git systems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Regarding codestyle stuff would you mind commiting yours then to some other branch? I don't think anyone would touch them unless really needed, the point is it simply makes it easier for either side to have a common base rather than checking what causes formatting hickups by hand.
Just commenting on the codestyle stuff, I really like editorconfig. It's tiny, non intrusive, easy to read and mantain, and most text editors support it either by default or via plugin |
@Souler LGTM. |
Refactoring by extraction
Extracted many core functions from the main
Arduino.cmake
script to separate, matching script files located under the Core directory.Renamed few of the functions to better suited names.
As for the Script-driven approach discussed in #12 , the entire code is divided into scripts yet most of the scripts contain functions, which doesn't affect the approach since a new implementation of a function can be used by simply including a different script file.