On 20.04.2010, at 04:15, Michael Surette wrote: [me:] >>>> 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.
[Mike:] > ... 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. That might be true. I don't know who wrote the previous CMake files, but I had the impression that this was someone who was close to the CMake development (might be completely wrong). > 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 think that this should be done anyway. See below... > I believe this is the next best option after > > 1) making a copy of FL or I'm not yet sure about this. > 2) creating them in the source dir. We can definitely rule out this ! > I don't believe the FLTK code itself relies on them, and they are just > for user convenience and legacy code. Yep, that's true. In fact, they would be counter-productive. Let's rethink the task: Rule #1: Don't change the source dir! Rule #2: We don't want the symlinks in the build dir. Rule #3: We shouldn't copy the header files to the build dir. Rule #4: Symlinks should only be created in the install phase. Details: Rule #1: This should be obvious. We can have different build dirs for different targets at the same time, or with different options. Rule #2: Developers shouldn't have the symlinks in the build dir, because they would hide misspellings rather than detect them. This is also for compatibility with the current make system. Rule #3: I'm not yet sure about this one. There could be a conflict for different scenarios: (a) FLTK developers don't want the header files copied because they would be redundant, and header changes in the source dir wouldn't be detected by the CMake/make build (I just checked it with my current build). Which file to edit, how to commit changes? (b) End users that prefer not to install FLTK might need the header files in the build dir for "/path-to-build-dir/fltk-config --c(xx)flags" to work correctly. I'll have to check this. Maybe we can make it work that fltk-config detects this by a small modification, similar to what it does now (with the /lib dir, IIRC). Such "end users" would maybe also be cross-compiler users for embedded devices. Rule #4: Whether we copy the header files (rule #3) or not, this would also be for compatibility with the current configure/make implementation. Of course, they would only be installed, if the --with-links option or its CMake equivalent is set. I don't think that this would be too hard to do, the code is basically there. But you should know better. > 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, I can't stop telling you how much this is appreciated! > it may be worth learning. Yes, and it's not that difficult. If you know how to checkout a svn copy, that's almost all you need to know. Use "svn up [-r nnn]" to update to the newest version (default) or a particular release with -r nnn. Then, use svn diff always from the root dir, and that's it. This will also show the working copy release automagically in the diff file (good for reference when posting patches). If you need to add or delete files (as you did in your previous patches), then you also need "svn add" and "svn rm" or "svn delete". See "svn help command" for a particular command and its aliases. It's also worth learning it for own projects, but that's a little more work, although easy in the simplest form. Create a repository and use it with "file:" access is not very difficult. Reading the docs is recommended, though. > As you imply, keeping my working copy > in sync with the master would make sense. Exactly. And there's nothing that keeps you from having more than one working copy with different states for development of different aspects of a patch or different tasks. Albrecht _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
