Need Help using different libraries that have common files

Hey I am currently trying to use a header file that I separated out from the WaveRP library into its own library because i find it useful. The file is the mcpDac header file which allows me to communicate with the dac on the adafruit wave shield for when want to use it in my own code. The problem is when I include mcpDac.h from the sketch the Arduino IDE goes into the WaveRP library and tries to compile WaveRP.cpp even though I only included the mcpDac.h header file in my sketch. It comes back and tells me the compile failed with a bunch of errors probably related to the fact it is expecting the WaveRP.h to be included. How do i get the IDE to use the mcpDac.h from the mcpDac library and not WaveRP?

You don't.

Header files go hand in hand with the cpp files. The header file is incomplete without the cpp file, as the bulk of the actual code is in the cpp file.

infomaniac50:
Hey I am currently trying to use a header file ...

When you include a header file in your sketch and you tell Arduino to compile that sketch, the Arduino Magical Mystery Tour goes through all of your libraries looking for a header file with that particular name.

If you want to abstract some header information to some other file, don't just make a copy of the file. Copy whatever content you want and then give the file a different name.

The new header file name should not be the same as any other file name anywhere in any of your other libraries or in any of the Arduino distribution libraries. If this newly-named header file is going into a new library of your own construction, put the newly-named header file into the new library directory along with whatever other stuff that library needs.

If the header only contains typedefs and #define directives and other things that do not actually allocate storage or generate code, that's all you need. For example function template definitions do not actually generate code.

Regards,

Dave

@jraskell So you can't use a header file without it compiling a cpp file. btw the header file does not have its own cpp file it just has a bunch of inline functions in it. However it is referenced by WaveRP.cpp

@davekw7x I started out programming dotNET so i am used to write once, reuse everywhere so i guess thats why it doesn't make sense to me.

So what happens when two totally separate libraries have the same file or just a file with the same filename?

infomaniac50:
...doesn't make sense...

All I can say is that by collecting and deducing information from your main sketch, the Arduino Magical Mystery Tour is set up to try to shield beginners (and not-so-beginners) from lots of the things that "real" C++ programmers have to know to do their jobs. Things like Include file paths, function prototypes, etc. The result is that experienced programmers who are new to Arduino sometimes just can't believe that their knowledge and "standard operating procedures" and "good programming practices" and, sometimes, just absolutely standard C and/or C++ usage just don't transfer directly to the Arduino Way.

When I get really frustrated (it happens, but not very often), I just create a Makefile and compile everything in ways that I know and get stuff from places that I know. For me, it's (usually) not worth the trouble for the "typical" little Arduino projects that I do.

If someone asks, "What happens if you ..." sometimes the best answer is: "Try it and tell us. Then we will all know."

The actual way Arduino looks for things and puts things together has changed a couple of times since I started with Arduino (about ten months ago). Because of the moving target aspect of things, I haven't tried (and don't want to try) to understand how the java part of Arduino gets things ready to hand off to avr-gcc.

When you first start the Arduino IDE, it takes inventory of all libraries in the Arduino distribution path and in your own sketchbook/libraries path. Finds header files that are in libraries. Finds cpp files in libraries. Etc. Figures out how to work things out if your sketch includes a particular header. That general information is (just about) all that I know. Even that little bit makes my head hurt.

[/begin Standard YMMV Disclaimer]
Stuff that I have experimentally determined to be correct as of this writing might not hold true for the next release.
[/end Standard YMMV Disclaimer]

As a matter of fact, we may find that specific and detailed knowledge of lots and lots (and lots) of Arduino distribution libraries, and other Arduino stuff, that we all know and love (or not) may be rendered obsolescent (or downright obsolete) by the release (some time this Summer, I think) of the long-awaited Arduino Version 1.0.

Bottom line (for me): Experiment until you find something that works (like renaming copied header files to something else, for example). Don't get too comfortable with any "clever" (or not) workarounds that you find now. Don't brag about how you outsmarted the wizardry contained in the usual Arduino Magical Mystery Tour. (See Footnotes.)

Regards,

Dave

Footnotes:
"The mighty words of the proud are paid in full by might blows of fate,
and at long last these blows will teach us wisdom."
---Sophocles
Final chorus of Antigone

"Well---the part about the 'blows' is spot on. Still waiting for the 'wisdom' part."
---davekw7x

"It's what you learn after you know it all that counts."
---John Wooden

So it's worse than this... The Magical Mystery Tour brings in ALL SORTS of extra files. Here's a case I am confronting right now.

I am adapting a DS1307 RTC lib to support both that and the DS3234. So I have three sets of h/cpp files:

  • RTC.h/cpp: Contains the common bits, including the DateTime class
  • RTC_DS1307: Specific stuff for this chip
  • RTC_DS3234: Specific stuff for this chip

In a sketch, I include RTC.h and RTC_DS3234.h. ALAS, the compiler decides to thrown in RTC_DS1307.cpp into the finished product! AARGH.

The reason that sucks in this case is that one chip uses I2C, and the other SPI, so I really don't want users to have to bring in the Wire library to use the SPI chip, and vice versa.

A makefile is the right answer for me, but I'd really like to have a library that regular users can use with the IDE. :stuck_out_tongue:

Out of curiosity how did (does) C programmers organize their 'library' type functions prior C++ classes?

Lefty

retrolefty:
Out of curiosity how did (does) C programmers organize their 'library' type functions prior C++ classes?

Lefty

I can't speak for all C programmers but here's what I did and here's what I do:

For things other than command line functions, the project organization depends on the tools used: Qt (actually that's C++), Microsoft Windows API (Does anyone actually use "raw" Windows API anymore?) , etc...

For command-line projects here's my approach:

I usually create a simple (or, maybe not-so-simple) Makefile and use the "make" utility so that only files that have been changed must be recompiled before linking everything together. GNU make is my preference, but Borland make.exe and Microsoft nmake.exe are also somewhat usable with those compilers on Windows systems.

The main() function and some closely related specialty functions will be in a single file.
For "library" type functions, I may put all related functions in a C file, maybe named "something.c"

Typedefs, manifest constant declarations or #defined values go into a header file along with function prototypes, inline functions, etc. with the same base name: "something.h"

If there are any variables that are defined in "something.c" that should be available to other files/functions, they appear in an "extern" statement the header file.

There is always enough information in "something.c" to be able to compile it separately. Typically, it would include "something.h" It would also include any other headers (standard library or project header files) that would be required to compile it into an object file.

Compiling of any file with functions that call functions in "something.c" requires only that the header file be included.

All project files are compiled into separate object files.

Finally, all files are linked together into an executable file with a main() function. Typically standard library files are automatically linked, but some compilers require specific linking to things like the math library.

When all of the "library" functions have been debugged, create a library (GNU calls it an "archive") that contains all of the object files of the library functions. Then programs that need these functions include the appropriate header file and link to the library. (Either a .a file or a .so file for GNU stuff; a .lib or .dll file for some others.)

Regards,

Dave