Bryan Flynt wrote: > Another thought I've had is: My Linux distribution comes with fltk > version 1.1 installed for use by some other programs but I compile > and link against version 1.3 which I've built in my project folder. > The fltk header files in version 1.3 such as FL/Fl_Gl_Window.H > include Fl_Window.H in the following fashion. > > #include "Fl_Window.H"
Note that this is "Fl_Window.H" and not <Fl_Window.H> There's an important difference. If your compiler tool chain is well behaved, then it should look for files marked by quotes "" in the local directory first, and only search the path if it does not find them. Files with <> brackets get searched for in the compiler path... > If it tries to to look where I have pointed it for the includes it > will not find the file because my include path expects all fltk > headers to prefixed with the FL directory. Then if it defaults to > look at the system level includes (i.e. /usr/include) it could > potentially find a matching header name although for version 1.1. Yes you do need to be careful about "cross-fertilisation" between your fltk-1.1 and fltk-1.3 trees. That said, I have fltk-1.1 and fltk-2 *installed* on this box, and actually I mostly build using fltk-1.3 directly from its build tree, and don't *usually* have problems with getting things crossed. Although I did have a few funnies when I first started... A little rigour in my Makefiles cleared that right up though! > For now I think I'll just place my GUI in one big file but what a > pain. That should never be necessary - we need to understand why this is happening and do the *right* thing. Ignoring it or working around it might be masking something more heinous! Maybe you can post a minimal example of what you are doing, or your Makefile or something? Maybe somebody will spot something. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
