Project specific globals in separate file? #544
revision29
started this conversation in
Ideas
Replies: 2 comments 6 replies
-
On Sat, Nov 25, 2023, 8:02 PM Joe Schneider ***@***.***> wrote:
So, in my inability to observe things that are right in front of my face,
I just noticed that in effects.cpp it checks for the existence of
custom_effects.h and loads effects from it if present. This bypasses all
of the other effects in the following elif conditions. I have been
cluttering the effects.cpp file with effects related to the several
projects in progress. "Finding" this bit of code will help me clean up my
code some.
I created that and it was exactly my intention. Glad it helped!
Then, it occurred to me, should "we" do the same for the globals.}}9⁰⁰h
file? Something like custom_globals.h. This would help separate
I'd thought about it, but IMO adding more to that file is earely a good
idea. Almost every time I started there, I recognized that adding a define
to the top level build (and outside the source tree) scratched my itch
perfectly.
That's probably not true for every combination.
placed in the globals.h file. It's super easy to implement (I just did
while typing this post).
I'd gladly review or even create a new one.
I got hung up at one for boards, one for defaults, one for effects, and so
on. Let's not let the perfect be the enemy of the good.
Just thought I would run the idea here instead of using a PR to vet an
idea as I normally do.
That's probably not a bad idea anyway... Get consensus before you commit to
slinging bits unless you're committed to keeping those bits in your own
trees forever.
RJL
… —
Reply to this email directly, view it on GitHub
<#544>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD33GE4MEGJZTPBCBOILYGKIKPAVCNFSM6AAAAAA72OX6RCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVHA4DSOJWGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
This is exactly what I mentioned in this comment on #538. As that comment states, I don't think there's any harm in replacing #if __has_include ("custom_globals.h")
#include "custom_globals.h"
#elif DEMO It doesn't address the fact that there are defines before and after the configuration blocks, but it does give more freedom to "play" with defines without impacting the main globals.h. Also, it provides the possibility without any obligation to use it. |
Beta Was this translation helpful? Give feedback.
6 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
So, in my inability to observe things that are right in front of my face, I just noticed that in effects.cpp it checks for the existence of
custom_effects.h
and loads effects from it if present. This bypasses all of the other effects in the following elif conditions. I have been cluttering the effects.cpp file with effects related to the several projects in progress. "Finding" this bit of code will help me clean up my code some.Then, it occurred to me, should "we" do the same for the globals.h file? Something like
custom_globals.h
. This would help separate the "stock" configurations from the one's defined by the user. This would greatly reduce my fear that a sync with main would nuke the several custom sections I have placed in the globals.h file. It's super easy to implement (I just did while typing this post). Just thought I would run the idea here instead of using a PR to vet an idea as I normally do.Beta Was this translation helpful? Give feedback.
All reactions