Re: [Doxygen-develop] CMake
Brought to you by:
dimitri
Menu
▾
▴
Re: [Doxygen-develop] CMake
|
From: Dimitri v. H. <do...@gm...> - 2013-06-09 21:53:00
|
Hi Robert, On Jun 9, 2013, at 23:13 , Robert Dailey <rcd...@gm...> wrote: > The problem with depending on linux package managers is that you won't > be able to use those libraries on Windows or MacOS. So, as annoying as > it is, maintaining the packages yourself is the most portable > solution. Then CMake doesn't offer a solution for those. So it seems the solution will mostly be for Windows (MacOS can be treated as a Unix flavor as well). So maybe we should rethink what the problem is that we are trying to solve and if CMake is indeed the solution, or if adding some extra rules to the Doxygen.vcproj file will do just as well. > > What linux platforms/distros does Doxygen need to support? Well there are many Linux distro's that now bundle doxygen (Ubuntu, Fedora, RedHat, Mint, Debian, Arch, Gentoo, etc.) and then there is BSD (Free, Net, Open, DragonFly flavors) and Solaris (Sparc/x86) and maybe some more exotic Unix flavors. I do not provide packages for any of those, but package maintainers should be able to build doxygen using the other packages. > Which third party libraries are we referring to? For building: perl, python, flex, bison, sed For compiling: Qt4 (for Doxywizard), Xapian (for doxysearch), libclang (for clang support), libmd5 (now bundled with doxygen). Install time: LaTeX for generating the manual. Runtime (optional): Graphviz, mscgen, bibtex, epstopdf, dvips Note that a number of these package depend on other packages themselves. Regards, Dimitri > > On Sun, Jun 9, 2013 at 2:18 PM, Kevin McBride <dol...@ai...> wrote: >> Robert, >> >> That sounds like a good idea. I will leave the final decision to Dimitri, >> as he is the one who will have to commit the changes to GIT. >> >> >> Kevin McBride >> dol...@ai... >> >> >> -----Original Message----- >> From: Robert Dailey <rcd...@gm...> >> To: Kevin McBride <dol...@ai...> >> Cc: Doxygen <do...@gm...>; Doxygen Developers >> <dox...@li...> >> Sent: Sun, Jun 9, 2013 1:45 pm >> Subject: Re: [Doxygen-develop] CMake >> >> I think what I will do is redesign my framework to take a hybrid >> approach. I have a manifest file where you define the third party >> libraries plus their versions. I will change this so you define >> whether or not to download from a custom repository or download from >> package manager. In the latter case, you will need to define a script >> that takes a library name and version. This script will execute the >> platform's package manager to make sure that the appropriate includes >> and binaries are downloaded (or compiled) as part of the process CMake >> goes through to prepare third party libs for usage. >> >> I know that most linux distros have very different package managers. >> Syntax is different, and some download binaries while others download >> source. The source case will be difficult, as this custom script will >> not only need to invoke the platform's package manager to download the >> source but also build each package the moment it is downloaded in some >> uniform way. Does this seem feasible? >> >> On Sat, Jun 8, 2013 at 6:42 PM, Kevin McBride <dol...@ai...> wrote: >>> >>> Another area to consider is the standard C/C++ libraries. I have >> >> read the >>> >>> info behind the libraries, and found that this is where you could run >> >> into >>> >>> problems, as every std library is configured differently to make >> >> system >>> >>> calls to the Linux kernel. It is much better to compile dependencies >> >> during >>> >>> the actual building process (like the QTools package in doxygen's >> >> source >>> >>> code). >>> >>> When I used to compile RPMs (I was the one who came up with the `make >> >> rpm' >>> >>> command to the makefiles of Doxygen) I compiled under the Fedora >> >> distro, >>> >>> which had a dynamic libpng installed. I always had the linking >> >> process >>> >>> dynamically link to the libpng in the Fedora distro. The libpng >> >> dynamic >>> >>> linking enhancement was not included in the master repository because >>> Dimitri and I found only a small speed difference when using libpng >> >> that >>> >>> some distros provided. >>> >>> Can cmake do a configure process just like what is currently done to >> >> compile >>> >>> the doxygen source code? I really do think it is best to link >> >> dynamically >>> >>> to the common libraries that almost every distro has. You run into >> >> less >>> >>> problems this way, especially considering the example that the binary >> >> form >>> >>> of the standard C/C++ libraries do differ from distro to distro. >>> >>> >>> Kevin McBride >>> dol...@ai... >>> >>> >>> -----Original Message----- >>> From: Robert Dailey <rcd...@gm...> >>> To: Kevin McBride <dol...@ai...> >>> Cc: Doxygen <do...@gm...>; Doxygen Developers >>> <dox...@li...> >>> Sent: Sat, Jun 8, 2013 4:43 pm >>> Subject: Re: [Doxygen-develop] CMake >>> >>> Suppose you have a library on linux called D. The dependency tree is >> >> as >>> >>> follows: >>> >>> D -> B, C >>> B -> A >>> >>> So basically: D depends on libraries B & C, while library B depends on >>> library A >>> >>> In this case, you'd compile all 4 libraries on your target toolchain >>> and architecture (GCC + Intel) and put that in your CMake repository. >>> Would these 4 binaries not be usable on multiple distros? As long as >>> the kernel is the same (or at least compatible), it should work fine. >>> The only edge case I can think of is if the kernel is vastly different >>> on each distro, meaning things like the memory manager changes and >>> thus libraries would need to be recompiled for each kernel. >>> >>> On Sat, Jun 8, 2013 at 3:10 PM, Kevin McBride <dol...@ai...> >> >> wrote: >>>> >>>> >>>> Robert, >>>> >>>> Unlike Windows, Linux is written in a way that allows many different >>>> "distros" to be written. Some people prefer not to compile packages >>> >>> >>> from >>>> >>>> >>>> sources (Fedora is good for these people). Others that prefer to >>> >>> >>> compile >>>> >>>> >>>> from sources would typically use a distro that is more friendly to >>>> developers. >>>> >>>> With such differences, it is not wise to use one binary for all Linux >>>> distros. In fact, new stuff that gets compiled would be replaced >>> >>> >>> with old >>>> >>>> >>>> dependencies, resulting in chaos for developers as they try to stick >>> >>> >>> with >>>> >>>> >>>> their preferred versions of libraries and programs they have >> >> compiled. >>>> >>>> >>>> I once thought the autotools were good for doxygen, but the autotools >>> >>> >>> are >>>> >>>> >>>> good only on *nix platforms. They do not perform well on Windows. >>>> >>>> Hope this brief explanation about Linux helps. >>>> >>>> Kevin McBride >>>> dol...@ai... >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Robert Dailey <rcd...@gm...> >>>> To: Dimitri van Heesch <do...@gm...> >>>> Cc: Doxygen Developers <dox...@li...> >>>> Sent: Sat, Jun 8, 2013 3:46 pm >>>> Subject: Re: [Doxygen-develop] CMake >>>> >>>> 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 >> >> <do...@gm...> >>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi Robert, >>>>> >>>>> On Jun 7, 2013, at 2:21 , Robert Dailey <rcd...@gm...> >>>> >>>> >>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> On Thu, Jun 6, 2013 at 4:03 PM, Robert Dailey >>>> >>>> >>>> >>>> <rcd...@gm...> 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 >>>> Dox...@li... >>>> https://lists.sourceforge.net/lists/listinfo/doxygen-develop >>>> >>>> >>>> >>> >>> >>> >> >> >> |
