On 04/20/2010 06:05 AM, Albrecht Schlosser wrote: > [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).
I googled Andy Cedilnik and Julien Jomier listed in the comments at one time. Both are/were employees of Kitware, the people behind CMake. >> 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. Ah, late night messages, I should have said now that these two have been ruled out. > 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. > I'll vouch for counter-productive. I was a user of the compatibility links but got bitten a few months ago. I re-installed FLTK with the links, but haven't used them since. > 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? > The build dir headers are after all just a copy. Always edit the source. You should be able to just blow away your build dir and not lose anything. > (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. > These users will lose the compatibility links. Since this feature is being eventually removed anyway though, they'll just be the first. > 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! > I just see it as no more than just giving back to the open source community in general and FLTK specifically. I don't have the time to learn the inner workings of something like FLTK, but this I can manage. >> 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 I've played around with mercurial and wish svn had its clone command, but I can already see the advantages of using svn. I will be submitting a patch shortly which will have the create symlinks option which creates symlinks on install and doesn't copy the FL dir as well as all previously submitted patches, which is what my working directory includes. I do have one more patch which I'd like to submit. I thought I had already submitted it as a feature request, but can't find it, so I must be mistaken. Under the MS VC++ build the debug libraries have a "d" appended to the library names, allowing debug and release libraries to coexist in the same dir. My patch extends this to all platforms. I have two questions. Is this something the developers want? Should it be the default or an option? Mike _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
