I'd have to rewrite the framework to handle the special case package handling, which would be significant work for what might be little gain. The system would have to be used for all platforms as it currently is. I'm not a Unix developer, so I'm not sure why Unix would be more difficult than windows. For example, pretty much every linux distro I know supports GCC with Intel architecture. Even if you need to support GCC + ARM, couldn't you easily maintain 2 sets of packages on Unix (That would be: GCC+x86 and GCC+ARM)?
Another reason why I prefer this approach on linux is because when you download libs through package managers on Linux, your build system can't really control what version you have. With this approach, we are in control of the packages, so we can guarantee the versions of our libs we use are those we have tested with. When we upgrade a library, we can perform regression testing and update the package system on the CMake side to use the new version. At this point I'd just like a bit of education on where the complexity lies on the unix side. Teach me a little and I might be able to come up with some ideas for you :) Thanks. On Sat, Jun 8, 2013 at 4:59 AM, Dimitri van Heesch <[email protected]> wrote: > Hi Robert, > > On Jun 7, 2013, at 2:21 , Robert Dailey <[email protected]> wrote: > >> On Thu, Jun 6, 2013 at 4:03 PM, Robert Dailey <[email protected]> >> wrote: >>> Starting a new discussion thread here in the dev mailing list for >>> CMake support. I'll be working on this over on my github fork: >>> https://github.com/rcdailey/doxygen >>> >>> I'll be spending my spare time on this so please forgive any slow progress >>> :) >> >> Concerning third party dependencies that you do not build yourself as >> part of your make command, would you be able to maintain your own >> binaries for these in a repository? >> >> I already have a CMake framework that I can drop into doxygen and use. >> To be the most platform agnostic, I have set it up to download >> archives of precompiled binaries for third party libraries from an >> FTP/HTTP/Windows file share of your choosing (configurable in CMake >> cache). Basically for every platform or toolchain you plan to build >> doxygen on or with, you will need to have include files + binaries in >> an archive. Those will sit in a repository and the CMake scripts will >> download them, extract them, and automatically setup include >> directories and dependencies for you. >> >> There are a couple of benefits to having this approach: >> 1. No need to search for these libraries on the system. The CMake >> scripts will always be able to guarantee that they are on the system >> since it will be downloading them from a repository you maintain. >> 2. Easier for new developers to just pick up the code and start >> building, since they do not have to spend time building libraries. >> 3. Windows doesn't have an apt-get (unless you use cygwin, which is >> just another dependency to worry about) mechanism, so this makes up >> for that and makes it super easy to get a build started on Windows. >> >> The downside, of course, is that this can become a maintenance problem >> if you have a ton of libraries and/or platforms or toolchains to >> support. >> >> Let me know how you want to approach this, as it will deeply impact >> the work. Personally I suggest we take this approach, assuming you can >> setup an FTP/HTTP server somewhere to pull down the archives. I will >> also post this in the dev mailing list, as I have created a dedicated >> thread there for CMake discussion. Join me there! > > It is not problem for me to host the packages, and I do need them myself when > I > build a doxygen release. So for Windows (32bit/64bit + debug/release flavors) > and > MacOSX (32bit+64bit intel fat binaries for OSX 10.5+) this seems like a good > approach. > For Linux, however, it would be better to depend on the packages that come > with > a distribution (there are too many distros to support). > > Can CMake be configured like that? or is it one approach or the other for all > platforms. > > Regards, > Dimitri > ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Doxygen-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/doxygen-develop
