On 04/19/2010 08:11 AM, Albrecht Schlosser wrote:
> On 19.04.2010, at 13:22, Michael Surette wrote:
>
>>> In general, I would prefer *not* to copy the FL directory instead, but
>>> currently we would need the symlinks to stay compatible. OTOH, we're
>>> thinking of removing the links anyway, and this will probably be done
>>> before the 1.3 release (at least we plan to make the default not to
>>> create
>>> the links: configure --without-links).
>>>
>>> That said, I can see three ways to go:
>>> (1) don't copy the FL dir at all, and don't create links
>>> (2) don't copy the FL dir, but create the symlinks (to the source dir)
>>> (3) copy the source dir and create symlinks
>>
>> There are two reasons I was copying the FL dir. That's the way it was
>> when I got here and I didn't like modifying the source dir itself in
>> making the symlinks. Neither is really a good reason.
>
> Hmm, I hope there's no misunderstanding. Of course, the first reason
> ("it's always been that way, don't touch it") is moot. But good for
> starting...
>
> The second ("I didn't like modifying the source dir itself in making the
> symlinks") is not what I meant. Please don't modify the source
> dir for CMake. But maybe I misunderstood you...
>
> If my proposal (2) was ambiguous: I meant to create the symlinks *in*
> the build dir, pointing *to* the source dir. Thus, the symlinks would
> reside in the build dir, but the actual files would not be copied.
>
>> I foresee no problems with implementing any of the 3 scenarios.
>
> That's fine, neither did I.
>
>>> The reason why I would like to stay with the source directory search is
>>> that we might have more directories to search in the future (FL/, fltk/,
>>> fltk2/, fltk3/, ...), and I don't even want to *think* of copying all
>>> directories.
>>>
>>> So, if you could manage to make solution (2) work, this would be my
>>> preferred way to go. Do you see anything I didn't see, or would this (2)
>>> be possible?
>>
>> I'll work on that tonight. I'll make it an option (default off) and
>> include the header changes.
>
> Thanks, that would be great. I won't commit any changes until your work
> is done, so that we have the same working base.
>
> I'll probably look into changing the default for the configure option
> (--without-links) meanwhile.
>
> BTW.: do you have subversion available? If you have it, creating patches
> like these would probably be much easier (just use svn diff in
> your working copy). This way you can also upgrade your working copy
> while you're working on a patch. Just my 2 ct.
>
> AlbrechtIt seems that I did misunderstand your proposal(2). I suspect that the original copying of the FL dir was to make the creation of the symlinks easier. They are relative symlinks to files in the same dir. Installation is then simply a matter of copying them. Creating them at install time in the install dir is not something that I have mastered... yet. I think that this is possible, but will take a little research. I believe this is the next best option after 1) making a copy of FL or 2) creating them in the source dir. I don't believe the FLTK code itself relies on them, and they are just for user convenience and legacy code. As a hobbyist, I've never needed to use svn beyond checking out the latest release of a package. With the amount of work I'm doing on this though, it may be worth learning. As you imply, keeping my working copy in sync with the master would make sense. Mike _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
