Am 26.02.2010 20:09, Matthias Melcher wrote: > > On 26.02.2010, at 17:56, Albrecht Schlosser wrote:
>> Why are you asking? Do you also want to write the CMake files with >> fluid? > > Yes. I think that the most important build environment that we need would be > covered by VisualC, Xcode, and of course makefile. But I also know that CMake > is often requested. So if it is in an OK state, I would add it soon. If it is > still weak, I would rather wait, because every change that goes into the > CMake environment also must be copied into Fluid then. I do fully agree for VisualC (because we developers don't have or use it usually), and I trust you and your experience with Xcode. The reason is that both are somewhat "static" for a particular programming environment. Our problem is typically to add some source files. If this can be done in one place instead of using different IDE's, that's really good. BTW.: It's great that you could generate the VisualC 6 IDE files! > Similar questions arise for CodeBlocks, Anjuta, BorlandC and whatever else is > out there. Would we increase the user base sufficiently to put this effort > in? At least maintenance is then quite low with the auto-generated files. Yes, sure; if we could generate the IDE files, that would be a big step forward. However, I have doubts concerning CMake :-( because CMake is something that can change rapidly. It's more like autoconf/configure than a static IDE. Recently we had to add some tests to detect the new glibc headers (scandir), and there are lots of files that contain some programming code in "CMake language" (just like configure.in) or even c/c++ code for the tests. If we would try to generate these files from within fluid, how would we put the "knowledge" how to do this into fluid? How would we manage changes? ... thinking ... Maybe a compromise would be the best, and we could generate parts of the CMakeLists.txt files that do mainly contain lists of source files. Or even better: find a way to use a simple include file that contains only the source file list and maybe some libraries (like the first part of src/CMakeLists.txt). This way we could generate the file lists whenever we add files, but leave the main programming/configuration logic in the edited CMake files. I really don't know which options exist in CMake already (like --enable-localjpeg etc.), or which don't, and I seem to remember that someone had problems to include FLTK as a project in another CMake driven project build system. That would be something that we need to do for full CMake support, but I can't see that this could be useful to do with fluid. Please don't understand me wrong. I don't want to say that the fluid approach is wrong, but we should probably concentrate on the file list part only for CMake. And maybe this part could be done, whether the rest of the CMake files is ready or not :-) Just my 2 (€)ct, but I'm open for better ideas. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
