Move build flags to project-side nim.cfg and support more micros - #4
Move build flags to project-side nim.cfg and support more micros#4dwhall wants to merge 3 commits into
Conversation
Previously, the nim compiler build flags were in the Python script. Since command-line settings prevent the use of any config file settings, this tool would overwrite a user's build configuration. We should avoid this. This commit moves the build flags to a new nim.cfg file that is copied to the user's project folder if one does not exist. This allows the user to change the build settings as needed. Two build flags, path and cpu, must be dynamically written into the config file because they come from the platformio values in the Python script. I added the "opt:size" build flag to nim.cfg. I also added a support for more microcontroller families. A lookup table is used to convert the $PIOPLATFORM variable to the CPU type used by the Nim compiler. The result is put in the "cpu" build flag in the config file.
Previously, the nim compiler build flags were in the Python script. Since command-line settings prevent the use of any config file settings, this tool would overwrite a user's build configuration. We should avoid this. This commit moves the build flags to a new nim.cfg file that is copied to the user's project folder if one does not exist. This allows the user to change the build settings as needed. Two build flags, path and cpu, must be dynamically written into the config file because they come from the platformio values in the Python script. I added the "opt:size" build flag to nim.cfg. I also added a support for more microcontroller families. A lookup table is used to convert the $PIOPLATFORM variable to the CPU type used by the Nim compiler. The result is put in the "cpu" build flag in the config file.
|
Hmmm. . . I have 2 projects that will build using this commit (with a nimbase from v2.0.0) and a couple other projects that won't build. The error I'm getting comes after the main.nim is build and it says, "Error: Nothing to build. Please put your source code files to the 'C:\Users....\proj\main\src' folder" |
|
Thank you for this! I unfortunately have a very busy week, so I won't be able to give a proper review and merge it until next week.
This might be caused by the change to the nimcache parameter. Previously it was a path that was calculated in python to be relative to the project source dir. Now it's in nim.cfg as "src/nimcache". I'm not sure how this is interpreted by the nim compiler, but if it's interpreted as relative to the working directory then it might matter from which directory you're invoking the command to build. |
|
Good observation, that feels like a promising lead to pursue. I'll see
what I can do.
…On Tue, Sep 3, 2024 at 2:47 AM markspanbroek ***@***.***> wrote:
Thank you for this! I unfortunately have a very busy week, so I won't be
able to give a proper review and merge it until next week.
The error I'm getting comes after the main.nim is build and it says,
"Error: Nothing to build. Please put your source code files to the
'C:\Users....\proj\main\src' folder"
This might be caused by the change to the nimcache parameter. Previously
it was a path that was calculated in python to be relative to the project
source dir. Now it's in nim.cfg as "src/nimcache". I'm not sure how this is
interpreted by the nim compiler, but if it's interpreted as relative to the
working directory then it might matter from which directory you're invoking
the command to build.
—
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABVK66VWBLKBJ35ZWUJAB3ZUVSS7AVCNFSM6AAAAABNOGINUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRVHAZDOMBVGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Previously, the nim compiler build flags were in the Python script. Since command-line settings prevent the use of any config file settings, this tool would override a user's build configuration. We should avoid this. This commit moves the build flags to a new nim.cfg file that is copied to the user's project folder if one does not exist. This allows the user to change the build settings as needed. Three build flags, path, cpu and nimcache, must be programmatically appended into the config file because parts of the value come from the platformio environment values in the Python script. I added the "opt:size" build flag to nim.cfg. I also added support for more microcontroller families. A lookup table is used to convert the $PIOPLATFORM variable to the CPU type used by the Nim compiler. The result is put in the "cpu" build flag in the config file.
|
just a small gripe - perhaps we could store the nimcache in a ./build folder instead of next to the source? I'm not super familiar with nim coming from other languages, but it feels like im adding a lot of "junk" into where I keep the source code. |
|
@rknell , I'll see what I can do, but I believe the cache is put at that location so the intermediate .c files can be found by PlatformIO. |
3 participants
Previously, the nim compiler build flags were in the Python script. Since command-line settings prevent the use of any config file settings, this tool would prevent a user's build configuration. We should avoid this.
This commit moves the build flags to a new nim.cfg file that is copied to the user's project folder if one does not exist. This allows the user to change the build settings as needed. Two build flags, path and cpu, must be dynamically written into the config file because they come from the platformio environment variables in the Python script.
I added the "opt:size" build flag to nim.cfg.
I also added a support for more microcontroller families. A lookup table is used to convert the $PIOPLATFORM variable to the CPU type used by the Nim compiler. The result is put in the "cpu" build flag in the config file.