Re: WG: AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES
wedekind wrote: Hello Brandon, thanks for your input. So you are the only person who ever builds your software? If other people have to build your stuff, you're making it a PITA for them, having to remember precisely what Qt directory to use. All this knowledge is locked up in your head, or in your docs, which nobody wants to read for such a trivial issue. If you ever pass the baton of maintenance on to someone else, people are not going to thank you. :) I guess you already had the joy of taking over some maintenance scripts from anyone else? I spent 1 year migrating the Chicken Scheme build from GNU Autoconf to CMake. I do not like things done in "odd" ways. That said, the problems of Chicken were more about missing Windows support / consideration than about anything deliberately done in a lazy manner. What was there, was pretty well done. The point is: I need a trusted set of libs to link against, so flexibly looking for _any_ version/edition of a needed lib won't do. Ok that makes sense. On Linux, people take all these huge stacks of open source libraries for granted. On Windows, it's a nightmare, because the libs are not built regularly on Windows and tend to break. The best defenses of that are to (1) minimize external dependencies, (2) keep one's own version of the library in the source tree, either building it or using a canonical binary. Does that make sense to you? Can you think of a better solution? Well, even doing the above, there's the question of whether you feel these compatibility issues should get resolved. That is, do you want more open source support burdens for yourself? You could make the bug reports to Qt, the reproducers, the test scripts, etc. In the long run, it might solve your build compatibility problems. In the short run, it is always a waste of your time. I'm pretty guarded about what projects I'll do that for nowadays. Really, only CMake. Even with CMake, I got lazy / desperately busy and didn't actually check whether all the good bugfixes they gave me for 2.4.4 beta were actually working. I just trusted that the Kitware guys had tested the stuff decently before committing it to CVS. They did, so when 2.4.4 shipped, I implemented all the new feature stuff, bumped the required version to 2.4.4, and didn't bother with backwards compatibility at all. It's a PITA writing if..else..endif to support multiple versions, especially when you're just working around old bugs that got fixed. I could have done that early, during the beta, if I wanted to "smoothly pave the way" for the future. But as it turned out, I certainly didn't have the time. Even when I finally did the fixes, I just sorta threw them over the fence and hoped they worked, with only minimal testing before I committed them. Nobody complained though. I think, in open source, when you're making $0 from it, eventually you cut corners. Too expensive to offer industrial grade migrations, where nobody ever sees a hiccup. Which suggests another method: can you draft other people into doing the build testing / bug reporting for the Qt mishaps, so that the Qt people are properly pestered and the FIND problems get resolved? In that school of thought, you leave some bugs available so that people will do something about them. This requires an audience with a vested interest in having your stuff work, though. No good if it's a personal project that no one else uses. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: WG: AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES
Hello Brandon, thanks for your input. > So you are the only person who ever builds your software? If other people > have to build your stuff, you're making it a PITA for them, having to > remember precisely what Qt directory to use. All this knowledge is locked > up in your head, or in your docs, which nobody wants to read for such a > trivial issue. If you ever pass the baton of maintenance on to someone > else, people are not going to thank you. :) I guess you already had the joy of taking over some maintenance scripts from anyone else? Without knowing my own "build infrastructure" I'd say: You're right, hard-coded/inflexible build scripts are a PITA. But in my case I had to weigh up flexibility against stability. I am using a set of libs, like Qt, DCMTK, etc. on every platform I'm building my software on. And I had to learn that there are subtle differences e.g. between different editions of Qt. It may be the qt-lib version 3.3.5 I need to load at runtime, but is it the open-source or the commercial edition? Since I am using the commercial edition of qt, every linux I want to build my software on almost certainly delivers the open-source-edition. The software does not even built (or runs) with the wrong edition. The other libs I'm linking against partly needed to be fixed or built in a special way. The point is: I need a trusted set of libs to link against, so flexibly looking for _any_ version/edition of a needed lib won't do. My solution was to have a fixed dir-structure that holds all needed libs and which is the same on every platform. So I only need to install this "lib-dir" on a fresh build-machine along with the build scripts and can start to build. If I remember correctly Bill Hoffman doesn't like environment variables very much. I think I have fixed the location of my needed libs for the same reason. Does that make sense to you? Can you think of a better solution? Cheers Marco ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: WG: AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES
Hello Brandon, thanks for your input. > So you are the only person who ever builds your software? If other people > have to build your stuff, you're making it a PITA for them, having to > remember precisely what Qt directory to use. All this knowledge is locked > up in your head, or in your docs, which nobody wants to read for such a > trivial issue. If you ever pass the baton of maintenance on to someone > else, people are not going to thank you. :) I guess you already had the joy of taking over some maintenance scripts from anyone else? Without knowing my own "build infrastructure" I'd say: You're right, hard-coded/inflexible build scripts are a PITA. But in my case I had to weigh up flexibility against stability. I am using a set of libs, like Qt, DCMTK, etc. on every platform I'm building my software on. And I had to learn that there are subtle differences e.g. between different editions of Qt. It may be the qt-lib version 3.3.5 I need to load at runtime, but is it the open-source or the commercial edition? Since I am using the commercial edition of qt, every linux I want to build my software on almost certainly delivers the open-source-edition. The software does not even built (or runs) with the wrong edition. The other libs I'm linking against partly needed to be fixed or built in a special way. The point is: I need a trusted set of libs to link against, so flexibly looking for _any_ version/edition of a needed lib won't do. My solution was to have a fixed dir-structure that holds all needed libs and which is the same on every platform. So I only need to install this "lib-dir" on a fresh build-machine along with the build scripts and can start to build. If I remember correctly Bill Hoffman doesn't like environment variables very much. I think I have fixed the location of my needed libs for the same reason. Does that make sense to you? Can you think of a better solution? Cheers Marco ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: WG: AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES
wedekind wrote: Hello Bill, The Find should be used all the time, because someone might install qt in a different place, and you want that to work. If you hard code the place in the CMakeLists.txt it will only work on some systems. Of course, you are right to advise me to use FIND. But I am not using CMake to distribute source-packages of my software. I only use CMake to build the software "locally" and to create binary distribution packages from these builds. So I can control the directory where to find the qt-lib for building. The user of the binary package needs to make the qt-lib detectable by the application or use the qt-lib distributed with the software. So you are the only person who ever builds your software? If other people have to build your stuff, you're making it a PITA for them, having to remember precisely what Qt directory to use. All this knowledge is locked up in your head, or in your docs, which nobody wants to read for such a trivial issue. If you ever pass the baton of maintenance on to someone else, people are not going to thank you. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
WG: AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES
Hello Bill, >The Find should be used all the time, because someone might install qt >in a different place, and you >want that to work. If you hard code the place in the CMakeLists.txt it >will only work on some systems. Of course, you are right to advise me to use FIND. But I am not using CMake to distribute source-packages of my software. I only use CMake to build the software "locally" and to create binary distribution packages from these builds. So I can control the directory where to find the qt-lib for building. The user of the binary package needs to make the qt-lib detectable by the application or use the qt-lib distributed with the software. Cheers Marco ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES
wedekind wrote: Hello Bill, Yes, it should be correct, and will be for 2.4.5 (which maybe coming sooner than later... :-( ) I am not quite sure why you would add it by hand if it does not exist... Well, I need this lib, the debug version of the qt-lib, only sometimes. I did not have installed it yet, but I have been using a CMakeLists.txt from another platform that required it. Since I was about to only build the release version of my system, I simply did not care about the missing debug-lib... Maybe I should use the FIND-commands of CMake to avoid always linking to this lib, even it is not present. But it is such a fundamental lib, that it should always be there and I am so lazy... ;) The Find should be used all the time, because someone might install qt in a different place, and you want that to work. If you hard code the place in the CMakeLists.txt it will only work on some systems. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
AW: AW: [CMake] AW: Wrong interpretation of "optimized" and "debug" Qt-libs in TARGET_LINK_LIBRARIES
Hello Bill, >Yes, it should be correct, and will be for 2.4.5 (which maybe coming >sooner than later... :-( ) >I am not quite sure why you would add it by hand if it does not >exist... Well, I need this lib, the debug version of the qt-lib, only sometimes. I did not have installed it yet, but I have been using a CMakeLists.txt from another platform that required it. Since I was about to only build the release version of my system, I simply did not care about the missing debug-lib... Maybe I should use the FIND-commands of CMake to avoid always linking to this lib, even it is not present. But it is such a fundamental lib, that it should always be there and I am so lazy... ;) Cheers Marco ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
