On 20.04.2010, at 18:02, Michael Surette wrote: >> 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.
No, that's not what I *want* to do during development, and that's not what make is designed for. Edit one file, make, run. But having the header files in the build directory means that I could accidentally edit the wrong file (and wonder why this doesn't change anything) and so on. Just a source of errors. >> (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. They don't lose the compatibility links (compared with configure/make), because they have never been there (and that's good so). The problem is that fltk-config --cxxflags (and others) would have to give the correct options (include path, library path). If we don't copy the header files, then fltk-config must return the source dir for the include path, but the build dir for the library path. But let's see... ... just tested. fltk-config in its current version doesn't work if I remove the FL (and Fl) directories from the build dir. It is testing for the existence of "$selfdir/FL/Fl_Window.H", but I think that this could be fixed somehow. I'm working on it ... > 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. TIA. > 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? I don't know. This would also mean that fltk-config would need an option to decide what you want. And maybe more. I'm not sure that this would be useful for commandline builds like make. > Should it be the default or an option? Please post another STR with your proposal and a separate patch, if you want, so that we can see it and decide. Thanks for this as well. Albrecht _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
