Greg Ercolano wrote: > > So if the user had: > > #include <FL/Fl.H> > #include <FL/Fl_Window.H> > #include <Fl/Fl_Button.H> // <-- casing error! > #include <FL/Fl_Input.H> > > ..then somehow either: > > 1) Fl_Input.H would need to detect the bad #include > for the Fl_Button.H above it, or > > 2) We'd need to have a separate fltk1.3.x/Fl directory > (note the casing) full of one liner #include files > that just have #error pragmas > > #1 is I think what your proposing, I'm just not sure I see > the trick? > > #2 is something I thought of before, but ruled it out cause > it seemed too messy; one file for each of our #include files. > > But thinking harder, maybe it's not so bad: it occurs to me > are /only/ needed in the /build/ directory (after a 'make'). > > The files /wouldn't/ need to be released by a 'make install', > and in fact 'make install' should /remove/ any old /usr/include/Fl > links.
This works only if you install to the same install prefix, but not if the new files are in a non-standard directory, while the old files are in the default search path. > I think this would solve the OP's issue, such that building > apps against an un-installed FLTK would effectively 'shield' > the app from the old /usr/include/Fl directory. Not really. See above. Maybe we should remove the links and don't think about catching errors any more. Future versions won't have these problems. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
