Re: [Doxygen-develop] CMake

[Kevin M. <dol...@ai...>]

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