Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
The build fails for me because rakarrack 0.6.1 has two places where an FLTK header is pulled from Fl/ instead of FL/ . Attached patch fixes that.
patch to fix include location
What OS, disto & version of FLTK are you using? On Debian Squeeze, the Fl path exists, and contains all necessary headers, and of course, the build succeeds either way. Actually, I have both directories, FL and Fl, with the same header files. This probably needs to be fixed with a pre-processor conditional so it doesn't break for everybody else.
All CAPS was used w/ FLTK v1.0, and Fl is used with FLTK 1.1, and on into the future of FLTK development. Debian probably provides both headers for backward compatibility so a change to the old way (FL) is a step in the wrong direction with regard to future FLTK development.
I'm using Source Make GNU/Linux, which is a source-based distro that tries to follow upstream closely. In the case of fltk-1.3, we just configure && make with some options set by the user. What is apparently missing for rakarrack:
--with-links make header links for common misspellings (default=no)
This option triggers that code in the resulting Makefile (by setting HLINKS to nothing):
@HLINKS@ cd $(DESTDIR)$(includedir)/FL;\
@HLINKS@ for file in *.H; do\
@HLINKS@ $(RM) "`basename $$file H`h";\
@HLINKS@ $(LN) $$file "`basename $$file H`h";\
@HLINKS@ $(RM) $(DESTDIR)$(includedir)/FL/fl_file_chooser.H
@HLINKS@ $(LN) Fl_File_Chooser.H $(DESTDIR)$(includedir)/FL/fl_file_chooser.H
@HLINKS@ $(RM) $(DESTDIR)$(includedir)/FL/fl_file_chooser.h
@HLINKS@ $(LN) Fl_File_Chooser.H $(DESTDIR)$(includedir)/FL/fl_file_chooser.h
@HLINKS@ $(RM) $(DESTDIR)$(includedir)/Fl
@HLINKS@ $(LN) FL $(DESTDIR)$(includedir)/Fl
So, this very much looks to me that include/FL is the normal spelling (along with .H instead of .h, but Fl_File_Chooser.H instead of FL_File_Chooser.H). In other distros, apparently --with-links is specified.
What a holy mess the FLTK folks got into for choosing varying camel-casing for theirs header paths; on a cross-platform toolkit where people write code on systems that do not care about case for paths... but also want to build it on systems that do.
Now, what also led me to believe that those two inclusions in rakarrack are typos is the fact that all other FLTK header inclusions use the FL/ path. Now, I somewhat prefer having rakarrack fixed to build with what looks to me like the default install of FLTK: include/FL/Fl_Some_Thing.H instead of enforcing folks to install FLTK --with-links.
In any case, what a casing mess.
Yes, I see. Maybe Holborn will pipe in ;/ Thanks for the information.
This is the first time I have really looked at the FLTK stuff since I usually code in the DSP side of things but Holborn knows his way around FLTK better. I will let him decide which way he wants to go to fix this (FL or Fl).
Thanks for reporting this issue and I agree it is clumsy how FLTK has done this, but I can certainly imagine circumstances in the evolution of FLTK development which probably led to this situation. Anyway, I will see what Holborn decides.