Greg Ercolano wrote:
> Albrecht Schlosser wrote:
>> This could be done by simply setting the default for our configure
>> option "--with-links" to "--without-links", so that users still can
>> configure their installs to have the symlinks. (Did you know that we had
>> this already ?) ;-)
>
> Sounds good.
>
>> The question here is: should we also set the default to --without-links
>> in fltk 1.1.10, so that distros will probably do the default install
>> without the header symlinks? Since FLTK 1.1 is now {really|probably}
>> final, this would be our LAST CHANCE to do this and to avoid the
>> problems discussed that old misspelled header names could leak in a 1.3
>> build.
>>
>> My vote would be +1,
>
> Yes, I'm still +1 as well on this.
Oh, and +1 for 1.3.
I don't know how to weigh in on changing 1.1..
I guess it depends on how clearly we can warn people about
the change;
-1 if no warning is used
+1 if the warning is clear (ie. configure warns with a big banner
when the old links are detected, and configure has links turned
off)
The big warning should probably include a URL to an article on the FLTK site
or a README file in the distro describing:
a) the details of why the links were disabled
b) short history of why they were added, then later removed,
c) what problem they create
d) what app builders should watch out for if they're on
e) what app builders should watch out for if they're off
(ie. crashing programs if links remain, or apps that won't
compile due to casing typos causing #include errors)
f) recommend how to fix the problem by telling people how to remove
the old links.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
