> > > Agreed, although we could use the symlink trick for all of the .H > > files to phase out .H in favor of .h (or create .H files that > > included the .h files after issuing a compile-time warning...) > > I like the idea of switching to ".h", but providing ".H" wrappers - > means it will work on winXX and so forth, where symlinks won't play. > > > Of course, the new "l33t" C++ header naming convention is to omit the > > extension entirely... > > And lets not do that...
This isn't really that big an issue either way, because as I found, the problem was easily remedied in my case. But I would like to point out that almost no other C++ library employs this .H/.h trick, and people manage to use those libraries just fine. In contrast, using the .H/.h trick: - Is unconventional and therefore surprising - In rare cases can lead to problems (as I found) - Makes the library just a tiny bit more complicated I imagine that you wouldn't want to change anything in 1.1.x and 1.3.x, because you don't want to break programs that #include the .H or .h files on case-sensitive systems. But for FLTK 2.x? I'd say there's a strong case for just going with ".h". _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
