gmane.text.doxygen.devel

Re: CMake

Bastiaan Veelo — 2013-06-18T20:08:39

Hi,

I must admit that I haven´t studied this in great detail, but if most 
binary dependencies are available for windows from somewhere, so that 
cmake would work well for 90% of the dependencies, one possibility for 
the remaining 10% would be to distribute binaries on the doxygen site 
for the sole purpose that cmake can download them from there. What are 
the percentages actually?

It may be an obvious thing to say, but I thought I´d bring it up 
nonetheless.

Bastiaan.

On 18-6-2013 19:17, Robert Dailey wrote:


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

Re: CMake

Robert Dailey — 2013-06-18T17:17:12

Sorry for the delay in response.

So basically the problem is between Windows and Linux. On Windows, I
do not have a package manager. It's a huge pain in the ass to download
each dependency, as well as its dependencies (transitively) and build
each individually. This takes sometimes days, and is impossible to do
depending on what libs you use. If anyon tried to build SVN on Windows
5 years ago, they would know what I'm talking about.

However on Linux, things are much easier in this respect. It's OK to
let the user install the dependencies because they just type in
apt-get and they are done.

find_package() is ideally the cross-platform way of handling
dependencies in CMake, but the problem is just that: Fulfilling the
dependencies, as I noted above, is rather painful on Windows. Not only
that, but CMake doesn't come pre-packaged with find modules for each
and every library known to man. For any libraries that CMake does not
know how to search for, you must write the corresponding find package
script. Grante

Re: FILTER_PATTERNS is working with additional " at the end

2013-06-17T17:40:10

Hello Dimitri

In the meanwhile I updated my doxygen-installation to 1.8.4 and tried 
out the behaviour of the configuration of  the FILTER_PATTERNS.
It is still the same like described in the bug-report   [Bug 700148] 
FILTER_PATTERNS is working with additional   "   at the end.

It doesn't matter if the filter is a script where I have to mention the 
script-interpretor also ( first example  with a perl based filter for 
matlab) or if the filter is a independent exe-file only ( second example 
with an exe-fileter for pascal).

You mention that the use of a batch-script is the solution. Is it 
possible for you to use both examples I added to my bug-report for 
creating examples how to use both filters with a windows bath-file?
Will this batch-file also be usable for  INPUT_FILTER?

Best regards,
                     Eckard Klotz.




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-

Re: CMake

Torbjörn Klatt — 2013-06-12T06:10:50

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all

On 12.06.2013 04:47, Anthony Foiani wrote:

Only ever do this for libraries which do not provide pre-built Windows
binaries or where most linux distributions do not provide packages
(which is very very rare).
And even then you really need to know what you are doing and should
prefer to let the use resolve these dependencies on his own. He/she
knows the system well better than you ever do via CMake.

CMake's purpose is exactly to overcome the need to create such
monstrosities of bundles and maintenance nightmares.


CMake does have such possibilities. It's called

FIND_PACKAGE(mypackage REQUIRED)

This will abort the whole configuration step if 'mypackage' is not
available on the system (read: not found in system's paths).

E.g. to require the Boost system and regex libraries and headers of
version 1.50 and later one writes

FIND_PACKAGE(Boost 1.50 REQUIRED COMPONENTS system regex)

For a list of somehow inbuilt supported packages to search for see [1]

Re: CMake

Anthony Foiani — 2013-06-12T02:47:57

Robert, Markus, all --

On Tue, Jun 11, 2013 at 12:05 PM, Markus Geimer <mg1102< at >web.de> wrote:

I very strongly concur.

Robert's proposal (create private copies of everything) was the route
taken by Chromium.  Getting it accepted into Fedora has been delayed
for years because the original packagers did not use the libraries
already available on the platform.

(Not to mention the fact that, with the "monster tarball" approach,
you also need to keep up with security patches for all of those
programs you copied...)

More info on this particular case here:
http://ostatic.com/blog/making-projects-easier-to-package-why-chromium-isnt-in-fedora


+1.

I can't believe that CMake doesn't have this capability already, even
if it's in the guise of "is this symbol available from any known
library on the system?"

Either way, I do wish Robert luck; CMake has the potential to improve
cross-platform projects quite a bit, but I agree with Markus that
bringing in tarballs of dependencies is not the right way.

Best regards,

Re: CMake

Markus Geimer — 2013-06-11T18:05:35

Robert,


I strongly recommend to *not* create such a monster tarball because of
various reasons:

 - Most importantly, it will become a maintenance nightmare. Someone
   needs to keep track of new versions of all the dependency packages,
   and based on the changelog decide whether an update is required for
   doxygen (e.g., when a security issue has been fixed) or not.

 - Additional burden is put onto the distro package maintainers, as
   they will most likely patch the sources to use the system-provided
   libraries instead of the included ones (this is, e.g., already the
   case for libpng on Debian and maybe other distros).

 - It will unnecessarily increase build times for 99% of the users
   which have the common libraries already installed (not such a big
   deal if parallel builds are working, but Qt will be a killer).


Builds are normally done as ordinary user, while installation of
packages is done as root. So, trying to install packages using a
package manager at build time of doxygen sounds cr

Re: CMake

Robert Dailey — 2013-06-10T17:13:23

The only other thing I can suggest to remedy the dependencies problem
is to bundle all dependency source code with Doxygen and build it
along with everything else, much like you already do for libmd5. This
also would include any dependencies of dependencies, transitively.
This doesn't seem like it would be too big of a deal except for QT,
which is pretty huge. Thoughts?

On Sun, Jun 9, 2013 at 4:52 PM, Dimitri van Heesch <doxygen< at >gmail.com> wrote:

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

Re: CMake

Dimitri van Heesch — 2013-06-09T21:52:50

Hi Robert,

On Jun 9, 2013, at 23:13 , Robert Dailey <rcdailey.lists< at >gmail.com> wrote:


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.


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.


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

Re: CMake

Robert Dailey — 2013-06-09T21:13:01

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.

What linux platforms/distros does Doxygen need to support? Which third
party libraries are we referring to?

On Sun, Jun 9, 2013 at 2:18 PM, Kevin McBride <dolphindddd< at >aim.com> wrote:

------------------------------------------------------------------------------
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

Re: CMake

Kevin McBride — 2013-06-09T19:18:42

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
dolphindddd< at >aim.com


-----Original Message-----
From: Robert Dailey <rcdailey.lists< at >gmail.com>
To: Kevin McBride <dolphindddd< at >aim.com>
Cc: Doxygen <doxygen< at >gmail.com>; Doxygen Developers 
<doxygen-develop< at >lists.sourceforge.net>
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 prepa

Re: CMake

Robert Dailey — 2013-06-09T17:45:16

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

Re: CMake

Kevin McBride — 2013-06-08T23:42:01

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 libr

Re: CMake

Robert Dailey — 2013-06-08T20:43:11

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 <dolphindddd< at >aim.com> wrote:

------------------------------------------------------------------------------
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

Re: CMake

Kevin McBride — 2013-06-08T20:10:00

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
dolphindddd< at >aim.com


-----Original Message-----
From: Robert Dailey <rcdailey.lists< at >gmail.com>
To: Dimitri van Heesch <doxygen< at >gmail.com>
Cc: Doxygen Developers <doxygen-develop< at >lists.sourceforge.net>
Sent: Sat,

Re: CMake

Robert Dailey — 2013-06-08T19:46:09

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 educati

Re: CMake

Dimitri van Heesch — 2013-06-08T09:59:19

Hi Robert,

On Jun 7, 2013, at 2:21 , Robert Dailey <rcdailey.lists< at >gmail.com> wrote:


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 linkifies arguments names

Aleksandr Platonov — 2013-06-07T14:59:45

Hi.
I think that behavior described in subj. is incorrect, e.g. argument
name could be the same as a typedef name
https://bugzilla.gnome.org/show_bug.cgi?id=640156

The problem is in line 1660 of src/memberdef.cpp file:
linkifyText() function is called for the whole argsString() thus
arguments names could be linkified.

I have created patch (see attachment) which replaces linkifyText() call
at line 1660 with loop which calls linkifyText() for arguments types and
default values and ol.writeString() for arguments names. This solution
looks like dirty hack, but I have no idea how this problem could be
solved in another way.

Is it really problem or expected behavior?
Could you take a look at my patch?

Re: CMake

Robert Dailey — 2013-06-07T00:21:46

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

Re: Problem with default values

Robert Dailey — 2013-06-07T00:21:08

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

CMake

Robert Dailey — 2013-06-06T21:03:53

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 :)

------------------------------------------------------------------------------
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

Re: Problem with default values

Dimitri van Heesch — 2013-06-06T20:39:37

On Jun 6, 2013, at 22:16 , Robert Dailey <rcdailey.lists< at >gmail.com> wrote:
Hi Robert,


Some things to carry over:
- options --with-doxywizard, --with-doxyapp, --with-doxysearch --with-sqlite3, --with-libclang, --with-libclang-static
- checking for flex, bison, perl & python (required for building), bison has to be version 1.35 or higher
- checking for Qt4 (optional needed for --with-doxywizard)
- checking for Xapian (optional needed for --with-doxysearch)
- checking for Sqlite3 (optional needed for --with-sqlite3)
- checking for libclang (optional needed for --with-libclang)
(for the current checks and options see the configure script)
- linking specific libclang/llvm libraries staticly (optional needed for --with-libclang-static)
- I build ce_parse.cpp and ce_parse.h from constexp.y with proper dependency tracking
- I create a bunch of .cpp files from .l files (flex), each using their own -p option.
- I create *_js.h from a bunch of .js files via a sed command (same for other 'resource' files)
- I post-pr