Go Down

Topic: library definition (Read 1 time) previous topic - next topic

mromani

The -D switch is on the command line what #define FOO is in the source code.

If you have an #ifdef DEBUG, and you compile with -D DEBUG, the #ifdef statement will evaluate to true.

newhobby

Yeah, I realized that after I posted. I use those to burn bootloaders.
But, how would I get to do that within the IDE?

mromani



You are in Dependency Hell (tm) ;-)

What about a features.h that gest included both by the .ino file and by all library header files ?


That's what I have been doing so far, and the whole purpose of this thread. I wanted to get rid of it.
The reason why is that to enable/disable features, the user has to actually edit a file features.h that has to be located on "Documents\Arduino\libraries\features", correct?
I would think any other place would make it invisible to all other libraries.
If so, let's suppose you enabled one feature today and uploaded. Then, you changed you mind and decided to go and use 3 other features and uploaded.
The INO code is the same for both and the only thing that was changed was 2 more defines on the features.h file.
A month from now, how would you know which features were compiled on the first code?
I wanted to place the defines inside INO to carry the history of features and make both INO codes different from one another.
Would you be able to explain a little better what the -D flag does and how to get it incorporated on the IDE, if you could?


Sorry, I didn't re-read you original question before posting my last comment.

What you have is a bounch of libraries and a sketch that can produce different programs based on which features the user enabled. If you want the compiled code to report its particular set of feature to the user once the build configuration is gone, you should find a way to compile in some sort of value that uniquely identifies each feature. (Cfr. e.g. squid or samba, whose binaries can print the list of the features the user selected at compile-time via the configure script.)
Off of top of my head, you could have a "features" unsigned int whose bits represent a particular feature. 1 = feature is present 0 = not compiled in.
You'd have a dump_features() function that would simply Serial.println(features, HEX) or, if you don't mind wasting some space, could print out the feature name for each '1' bit.


mromani

Oh, and there's always version control... not the easiest workflow if you're not used to it, but still a solution if you're willing to spend some time learning the basics of, say, subversion.

newhobby


Sorry, I didn't re-read you original question before posting my last comment.

What you have is a bounch of libraries and a sketch that can produce different programs based on which features the user enabled. If you want the compiled code to report its particular set of feature to the user once the build configuration is gone, you should find a way to compile in some sort of value that uniquely identifies each feature. (Cfr. e.g. squid or samba, whose binaries can print the list of the features the user selected at compile-time via the configure script.)
Off of top of my head, you could have a "features" unsigned int whose bits represent a particular feature. 1 = feature is present 0 = not compiled in.
You'd have a dump_features() function that would simply Serial.println(features, HEX) or, if you don't mind wasting some space, could print out the feature name for each '1' bit.

I agree that this solution would work for the code currently loaded on the board, but it would still not be enough.
What if I need to know which features I had enabled a month ago after uploading several codes.
Also, if one user wants to share the code with another user, simply giving out the INO file would not be sufficient.
And this is the biggest problem of them all.
If you simply post the INO file, the ending result is totally different from one user to another because what one user has inside the features.h file is different than the other one might have.
To be really honest, the INO file has nothing more than a couple of lines in it.
something like this:
Code: [Select]


<include TestClass1.h>
<include TestClass2.h>
<include TestClass3.h>
<include TestClass4.h>
<include TestClass5.h>
<include ParentTestClass.h>
<include features.h>

void setup()
{
  ParentTest.init();
}

void loop()
{
  ParentTest.DisplayScreen();
}


All the features are chosen from within the features.h
The best scenario would be to include the defines inside the INO file, which doesn't seem to be possible or in a file inside the same folder as the ino file, which would not really solve the problem 100%, but it would at least create history of codes if you saved the INO files with different names.


Go Up