-
• #2
You can't really - but when you get to that stage I think we need to think about blacklisting entire C files, not functions. If you blacklist individual init/kill/idle functions you're basically guaranteed to break something.
-
• #3
Lets start a discussion ;-)
blacklisting C files looks dangerous to me.
I could imagine to blacklist jswrap*.c files, but even that, at least for me, is like a mine field.
May be we could add some more defines to remove blocks of software, like waveformMy idea was to use wildcard to remove idle/init/kill which belong to a class
We could add class to wrapper with type idle
It could be set for waveform, and would be empty for pipe.Going through your list, I tried to get an overview what init idle and kill are used for
- init looks mainly important for some boards and for net, bluetooth. There is no need to blacklist them, we already have defines for that
- idle is used for waveform, serial and pipe. IMHO serial and pipe should never be blacklisted, waveform could be blacklisted
- kill usage is a mix, blacklist it for waveform should cause no problem
- init looks mainly important for some boards and for net, bluetooth. There is no need to blacklist them, we already have defines for that
-
• #4
I think blacklisting whole files is one of the safest ways to work since we try and keep all the code reasonably modular - Waveform especially should work really well if the file is just left out of the build.
But maybe defines are the way forward - as you note I think Waveform is the only thing where you can't disable it some other way so rather than trying to build some complex addition, we could just change that.
However I do wonder how much flash memory will be saved by disabling it - not much I imagine.
Taking waveform as an example, we have
"type" : "idle", "generate" : "jswrap_waveform_idle",
how could I recognize that this belongs somehow to class Waveform ?