This repository was archived by the owner on May 4, 2019. It is now read-only.
Refactoring: Prefer script-driven approach over function-driven approach #12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of calling functions located in dedicated files, those files became script parts themselves, allowing to simply include them in the script using CMake's 'include' command. Also extracted the 'register_hardware_platform' function to a script named 'RegisterHardwarePlatform.cmake', which sets the platform path explicitly, causing less modular code yet simpler in that there's no other use of this function through the entire project.
Further extracted the script to separate files, leading to a super-small initialization script - just as a clean, modular system should be.
It made the '${CMAKE_CURRENT_LIST_DIR}' prefix unnecessary in various 'include' commands. Note that their '.cmake' suffixes has also been removed.
Until now the function wrote an entire CMake script as a hardcoded string to a cached file, in order to calculate a target's firmware size. This commit changes it by extracting the hardcoded string into a valid, readable and easily editable CMake script, named 'CalculateFirmwareSize.cmake', located under the 'Extras' directory. Added another initializing script to completely replace the need for the function, including a script part instead, named 'SetupFirmwareSizeScript.cmake'.
…functions. It sticks with the script-driven approach, providing consistency.
Moved the 'find_file' command used to find SDK's version file to the 'DetectVersion' script. This results in an 'Initializer' script that only includes other script parts.
This is the last part that still was in the 'Arduino' script, now extracted to a script named 'LoadArduinoPlatformSettings' under the 'Initialization' directory.
The script is named 'SetupExampleCategories', located under the 'Initialization' directory. Also renamed the cached variable 'ARDUINO_EXAMPLES_CATEGORIES' to 'ARDUINO_EXAMPLE_CATEGORIES'.
|
@JonasProgrammer Can you please review this? |
|
Sorry for letting you down; I expected to have more freetime in the last weeks, but things turned out a little differently. That being said, now that a long weekend approaches, I should finally find some time. Sorrybeing aside, I'm astonished by the progress made here. Looking at it now, it feels like you can tweak things without fearing the whole Arduino.cmake building collapsing on you. |
JonasProgrammer
approved these changes
Oct 28, 2017
This was referenced Oct 31, 2017
Merged
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed earlier in #10 the project's dev team has come to a conclusion that the project should be refactored.
Initialization Refactoring
I started the process by extracting the very first steps taken in the build configuration, which is the initialization of the Arduino platform. However, during my work I noticed that there are two possible approaches here, both having their own pros and cons. Let's take a look:
Function-driven approach
Similar to Functional programming where different behavior is implemented by a number of
if-elseblocks in a dedicated function.For example: A
calculate_areafunction to calculate the area of various data structures. Each data structure is ashape, defining only basic information about the shape, without implementing any behavior.In our scenario, it can be achieved by defining functions to handle various tasks, split to files by their responsibility. For example: Setup of required
C Flagscan be done by calling the functionsetup_c_flags, passing it some parameters for extensibility.Script-driven approach
Similar to Object-oriented_programming where different behavior is implemented through Polymorphism.
For example: A base, abstract class named
Shapedeclares a method namedcalculate_area. For the code to implement different behavior for different shape types, we should derive from theShapeclass and override itscalculate_areamethod. It allows us to add new data types quicker, mostly suitable for a growing system.In our scenario, it can be achieved by extracting behavior into script, where each script is part of a bigger script, including one into another as necessary. It allows developers to add new behavior as required simply by creating a new script file, referencing the existing code to use it instead of the current one.
For example: Setup of required
C Flagswill be a script, included where needed in the calling script (Probably the one which setups the system). To change those flags drastically, a new script file can be created and included instead, keeping the old one for compatibility or usual cases.Summary
Honestly, I prefer the script-driven approach, at least at the stage of system initialization.
I've also accomplished more work on this branch, almost completing the refactoring process of this part.