doxygen-develop — List for discussing new features, submitting patches, etc.

[Doxygen-develop] Suggestions

[Peter M. <ped...@gm...>]

Hi dimitri + all .. yipee its git hub..


Can we enable the "Issues" on the doxygen repo, please..
Am looking at this
https://bugzilla.gnome.org/buglist.cgi?product=doxygen&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

and we can migrate.. even consolidate some manually..
I dont think it works thousg

But if we start parallel, then why not..
at least we want bugs issued, and fixed etc ;-))))
so its easy and quick and fast this way..

Travis is not buildng in my branch
https://travis-ci.org/daffodil/doxygen

Also
IRC
Has anyone got control of irc.freenode.net#doxygen
We can setup git hub to send a message to channerl on each push or
even send message unsuccesful etc..

Not sure if dimitri can add that as a BOT..

YIPEE..
Looks like travis has build doxugen _ gui

- next test = sqlite etc

regards
Pete

Re: [Doxygen-develop] [Doxygen-users] Doxygen's code repository has moved to GitHub

[Peter M. <ped...@gm...>]

On 21 May 2013 01:40, Ken Kazinski <kjk...@ya...> wrote:

> On a windows machine, what is a good tool to use to get the main repo?  I
> have been using commit monitor for the SVN repo and this tells me when
> there are new files and auto downloads them.  Is there a similar tool for
> GIT?
>

U can either use the github client == their proprietory and kinda an
interface.
http://windows.github.com/

or U can dowload the kinda native kit from
http://msysgit.github.io/
ie Git for Windows

The later is neat, because even the standard install gives once
cd c:\myGit
git clone gi...@gi.../doxygen/doxygen<https://github.com/doxygen/doxygen>
git clone https://me:myP...@bi.../f<https://github.com/doxygen/doxygen>
oo/secret-project

The snag is in the keys..
- The bitbucket authenticaltion works as its using http auth
- the git@git hub is read only.. so no problem
- But is u want to commit then u need to hace the "key" installed on local
matching remote
- the github windows client does that for you.. ie creates a ssh key and
logs u in etc
- the msys client, u have to deal with that (pain) yourself..

Depending on your skill level, windows.github is probably the easiest.. and
your up and running fast.. issues, merges etc and all.. as a paltform


Pete

Re: [Doxygen-develop] [Doxygen-users] Doxygen's code repository has moved to GitHub

[Peter M. <ped...@gm...>]

Peter Morgan wrote:
>>
>>> Best give I can give is to have the branches
>>> - master = the latest stable release
>>> - next = the next version and unstable
>>
>>
> One of the challenges with git is that is flexible and allows for many
> work flows. There isn't one "right way", but there are some common
> workflows.
>


> The most common workflow that I have seen is as follows:
> * most or all development happens on the master branch
> * each new feature gets it's own branch, which is merged or rebased with
> the master branch when it's mostly complete and doesn't break the build.
> * releases are cut as tags from master or from a version branch  or stable
> branch(i.e. potential branches: master, stable, 1.2.x, 1.3.x, tags: 1.2.1,
> 1.2.2, 1.3.1)
>

Yes indeed, we need to create the tags.. I should have mentioned that..

>
> My advice is somewhat contrary to Peter's:
> * branches are awesome, use them whenever developing a new feature. Local
> branches can easily be discarded if things don't work out. Use public
> branches in the git repo with some reservation,
> * You should use a new feature branch for each new feature in your local
> repo. Once the feature is ready for merging, then merge/rebase and push the
> changes to github.
> * Using a branch allows for you to easily switch between various
> works-in-progress.
>

Well, can I add, cos I 100% agree, there's ways of slkinning a cat/penguin
with git, particular in Sweden/Finland ..;-)
So the thought in my head is what "distributors" will use, eg the latest
ubuntu..deb or win.zip, installers..
I would assume that they would want master to be the "stable"
ie tag-1.3. == latest-stable == master
If changes are pushed to master in - which is what we all want as dev's,
the the distributors will be rebuilding every day...

This dilemma I know is from the flightgear.org, the  flightsim project..
which is why that thought is very much in my mind..
the issue there with master vs tag vs dev is huge..
so at least all the devs know that next is fun and not dangerous.. kinda..



>
> Peter's next+master workflow is what the Linux kernel uses. It kind of
> mirrors master+stable branches in other projects.
>
> didnt know that.. but it does that use odd for dev and even for release ..
is that a numbering schema.. ?


> One alternative workflow is called git-flow, which is outlined here:
> http://nvie.com/posts/a-**successful-git-branching-**model/<http://nvie.com/posts/a-successful-git-branching-model/>
>
> One of the best ways to develop is using a continuous integration model.
> In this model, each commit to "master" is compiled and run against a series
> of tests, to determine if the project is viable.
>
> Travis CI offers free continuous compiling/integration for open source
> projects. It even integrates with github:
> https://travis-ci.org/
>
> Whaw Jason.. snap.. ;-)
The travis job is here..im my branch atmo

And there is no make test...
But indeed we can build against it certainly..

means dimitri can now with an ipad, do a marge and make a tag and release..
from somewhere on something..


=== versioning ==
About revision Nos''
The problem is that the "current version" is hidden way in config..
What would be really helpful is to have a file "./version"
with the release eg 7.8.9
This means that a remote system can directly check that "file" and deal
with things..
Looking here at making release automatic builds..
ie a debian package, or windows install with nsis etc

== Travis ==
Have the travis kinda working of "daffodil" which is my github fork..
https://github.com/daffodil/doxygen
the config is here
https://github.com/daffodil/doxygen/blob/master/.travis.yml

Problem
To make travis work as a link..
The README is now a README.md with markdown

This is richer and better.....

Merge request is here
https://github.com/doxygen/doxygen/pull/1

Travis is real cool cos the binaries can be built there..

Anyway.. this is fun..

ALSO
===============
BUGS
===============
I'll be frank, I hate bugzilla, its a pain to even want to find a bug..

So can we enable the  Issues in GitHub please, and the lovely thing for
github is it integrates well..
There's a scipt and stuff here..
So need to bind the bugs to the source which is what git hub does well, eg
match bug against patch
http://stackoverflow.com/questions/7281304/migrate-bugzilla-issues-to-github-issue-tracker


regards
pete

Re: [Doxygen-develop] [Doxygen-users] Doxygen's code repository has moved to GitHub

[Ken K. <kjk...@ya...>]

On a windows machine, what is a good tool to use to get the main repo?  I have been using commit monitor for the SVN repo and this tells me when there are new files and auto downloads them.  Is there a similar tool for GIT?


--- On Mon, 5/20/13, Jason Edgecombe <ja...@ra...> wrote:

> From: Jason Edgecombe <ja...@ra...>
> Subject: Re: [Doxygen-users] [Doxygen-develop] Doxygen's code repository has moved to GitHub
> To: "Petr Prikryl" <Pr...@sk...>
> Cc: "Peter Morgan" <ped...@gm...>, "Dimitri van Heesch" <di...@st...>, "dox...@li..." <dox...@li...>, "dox...@li..." <dox...@li...>
> Date: Monday, May 20, 2013, 7:09 PM
> On 05/20/2013 10:15 AM, Petr Prikryl
> wrote:
> > Hi,
> >
> > Peter Morgan wrote:
> >> Best give I can give is to have the branches
> >> - master = the latest stable release
> >> - next = the next version and unstable
> > I am not that sure about the neccessity of
> > the branches when moved to Git. They should
> > probably be created only when the branch
> > is found to be neccessary. They can mostly
> > be local only.
> >
> > I suggest to use GitHub fork mechanism to
> > keep the project responsibility firmly
> > in Dimitri's hands (at least at the beginning).
> > The Pull Request seems to be visible enough
> > to decide whether to pull or not, or to use
> > only some changes...
> >
> > However, I have only limited experience
> > with Git, and I can be wrong ;)
> >
> > Petr
> >
> 
> One of the challenges with git is that is flexible and
> allows for many 
> work flows. There isn't one "right way", but there are some
> common 
> workflows.
> 
> The most common workflow that I have seen is as follows:
> * most or all development happens on the master branch
> * each new feature gets it's own branch, which is merged or
> rebased with 
> the master branch when it's mostly complete and doesn't
> break the build.
> * releases are cut as tags from master or from a version
> branch  or 
> stable branch(i.e. potential branches: master, stable,
> 1.2.x, 1.3.x, 
> tags: 1.2.1, 1.2.2, 1.3.1)
> 
> My advice is somewhat contrary to Peter's:
> * branches are awesome, use them whenever developing a new
> feature. 
> Local branches can easily be discarded if things don't work
> out. Use 
> public branches in the git repo with some reservation,
> * You should use a new feature branch for each new feature
> in your local 
> repo. Once the feature is ready for merging, then
> merge/rebase and push 
> the changes to github.
> * Using a branch allows for you to easily switch between
> various 
> works-in-progress.
> 
> Peter's next+master workflow is what the Linux kernel uses.
> It kind of 
> mirrors master+stable branches in other projects.
> 
> One alternative workflow is called git-flow, which is
> outlined here:
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> One of the best ways to develop is using a continuous
> integration model. 
> In this model, each commit to "master" is compiled and run
> against a 
> series of tests, to determine if the project is viable.
> 
> Travis CI offers free continuous compiling/integration for
> open source 
> projects. It even integrates with github:
> https://travis-ci.org/
> 
> Jason
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance
> monitoring service 
> that delivers powerful full stack analytics. Optimize and
> monitor your
> browser, app, & servers with just a few lines of code.
> Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

Re: [Doxygen-develop] Doxygen's code repository has moved to GitHub

[Petr P. <Pr...@sk...>]

> [...] any tips are welcome ;-)

I suggest to introduce the .gitignore file at the root level
with a directory that anyone can use for whatever. The reason
is that I would like to use some "private" subdirectory that
is near to doxygen's everything.

Sure, I can make my own fork, my own .gitignore, and I can
secretly decide what the name of the directory is to be.
However, the pull request/merge would not be that easy in such case.
The goal is to keep the .gitignore public. Because of that,
the private subdirectory should be named publicly.

It can be defined via prefix and the wildcard. I suggest 
to put the following line to the .gitignore:

__*/

i.e. two underscores, star, slash. This way, any directory
that starts with two underscores will be considered private.

This way, developers will be free to create whatever private
subdirectory they like, wherever they like.

The rule "the two-underscore prefix" is easy to explain.

Petr

Re: [Doxygen-develop] Doxygen's code repository has moved to GitHub

[Petr P. <Pr...@sk...>]

Hi,

Peter Morgan wrote:
> Best give I can give is to have the branches
> - master = the latest stable release 
> - next = the next version and unstable

I am not that sure about the neccessity of 
the branches when moved to Git. They should
probably be created only when the branch
is found to be neccessary. They can mostly
be local only.

I suggest to use GitHub fork mechanism to 
keep the project responsibility firmly 
in Dimitri's hands (at least at the beginning).
The Pull Request seems to be visible enough
to decide whether to pull or not, or to use
only some changes...

However, I have only limited experience
with Git, and I can be wrong ;)

Petr

Re: [Doxygen-develop] Doxygen's code repository has moved to GitHub

[Peter M. <ped...@gm...>]

Best give I can give is to have the branches
- master = the latest stable release
- next = the next version and unstable

Pete

[Doxygen-develop] Doxygen's code repository has moved to GitHub

[Dimitri v. H. <di...@st...>]

Hi,

As of today doxygen's code repository has officially moved to GitHub!
It can be found here: https://github.com/doxygen/doxygen

I plan to do changes as individual commits, so it is more easy to see
what code changes belong to a fix or feature. I also plan to do much more
frequent pushes, so you can more quickly use and test fixes. This also 
means that the changelogs will no longer be posted here. Stable releases 
will be tagged as such and the change log is then equal to the commit log 
since the last tag.

I still have to get a bit more familar with the possibilities and the best way
of working, so any tips are welcome ;-)

Enjoy,
  Dimitri

Re: [Doxygen-develop] FILTER_PATTERNS is working with additional " at the end

[Dimitri v. H. <do...@gm...>]

Hi Eckard,

On May 10, 2013, at 10:54 , Eck...@t-... (Eckard Klotz) wrote:

> Hello Developers.
> 
> After some additional tests and referring the archive again I'm sure that the configuration of FILTER_PATTERNS is not working or its usage is not documented completely.
> 
> Even if I use
> FILTER_PATTERNS = *.m=./folder/subfolder/m2cpp.pl
> the c-comment files will be analysed but not the matlab-files.
> 
> Doxygen gives me the warning that the perl-script "./folder/subfolder/m2cpp.pl can not be opened.
> Note, the double-quote " is part of the doxygen warning message and there is no double-quote at the end of the message.
> 
> Once a realized that, I tried to insert in the wizard-input as filter-pattern
> *.m=./folder/subfolder/m2cpp.pl"  (note the double-quote at the end)
> This results in the DOXYFILE the line:
> FILTER_PATTERNS = "*.m=./folder/subfolder/m2cpp.pl\""
> 
> 
> And last but not least it works now. Since I don't use the filter as INPUT_FILTER all c-like files will be analysed like expected, while all m-files will be preprocessed with the filter.
> 
> Again an additional double-quote with backslash is needed at the end of the filter-definition:
> FILTER_PATTERNS = "pattern=filter\""
> in the doxygen-wizard the input is : pattern=filter"
> 
> Please decide if this is the wanted behaviour (then it may be useful to extend the documentation) or if this is a bug in the part to call the perl-script.
> If you think this is a problem of the used perl-script I have added, please help me with some information and I will discuss this in the associated forum of matlab.

A pair of quotes should only be needed in case the path contains spaces.
You should not need to add a dummy " or \" in the configuration file.
Can you file a bug report with a self-contained example that allows me to reproduce the problem?

Regards,
  Dimitri

[Doxygen-develop] FILTER_PATTERNS is working with additional " at the end

[<Eck...@t-...>]

Hello Developers.

After some additional tests and referring the archive again I'm sure 
that the configuration of FILTER_PATTERNS is not working or its usage is 
not documented completely.

Even if I use
 FILTER_PATTERNS = *.m=./folder/subfolder/m2cpp.pl
the c-comment files will be analysed but not the matlab-files.

Doxygen gives me the warning that the perl-script 
"./folder/subfolder/m2cpp.pl can not be opened.
Note, the double-quote " is part of the doxygen warning message and 
there is no double-quote at the end of the message.

Once a realized that, I tried to insert in the wizard-input as 
filter-pattern
 *.m=./folder/subfolder/m2cpp.pl"  (note the double-quote at the end)
This results in the DOXYFILE the line:
 FILTER_PATTERNS = "*.m=./folder/subfolder/m2cpp.pl\""


And last but not least it works now. Since I don't use the filter as 
INPUT_FILTER all c-like files will be analysed like expected, while all 
m-files will be preprocessed with the filter.

Again an additional double-quote with backslash is needed at the end of 
the filter-definition:
 FILTER_PATTERNS = "pattern=filter\""
 in the doxygen-wizard the input is : pattern=filter"

Please decide if this is the wanted behaviour (then it may be useful to 
extend the documentation) or if this is a bug in the part to call the 
perl-script.
If you think this is a problem of the used perl-script I have added, 
please help me with some information and I will discuss this in the 
associated forum of matlab.


I use doxygen 1.8.3.1 on Windows XP SP3

Best regards,
                      Eckard Klotz.




> Hello Everybody.
>
> For my nassi-shneiderman generator for doxygen 
> (https://sourceforge.net/projects/moritz/) I'm working on an interface 
> for the programming-language matlab.For a first demo-release I created 
> some example-sources which I want to use together with my already 
> existing c-based  description of the general function of Moritz to 
> create with doxygen a documentation. This means I have some txt-files 
> with c-comment blocks (where I have defined *.txt as FILE_PATERNS). 
> This c-comment-blocks contain doxygen group- and page-definitions 
> which are traditionally used from me as description of the language 
> independent parts of the documentation. In addition I have some files 
> which contain comment-blocks in the programming-language for what I 
> want to add examples.  For python this works very good, since doxygen 
> is already able to understand python-files as well as c-files. But 
> since doxygen does not know matlab, I have to use a perl-filter for 
> those files. The perl-filter itself works well as long as I only use 
> my matlab-files. But I'm not able to configure doxygen to use this 
> filter for matlab-files only and to use its own build-in c-parser for 
> all other files.
>
> If I use
>  INPUT_FILTER = "perl ./folder/subfolder/m2cpp.pl"
> all matlab-files will be parsed correctly but the files with the 
> c-comments will be ignored.
>
> If I use
>  FILTER_PATTERNS = "*.m=perl ./folder/subfolder/m2cpp.pl"
> doxygen tells me that the perl-script can not be opened. The c-comment 
> files will be analysed but not the matlab-files.
>
> I had the idea to use
>  INPUT_FILTER = "perl ./folder/subfolder/m2cpp.pl"
> together with
>  FILTER_PATTERNS = "*.txt=?????    to use the perl-fileter as 
> default-filter and to deactivate it for the txt-files which contain 
> the c-comment blocks. But I don't know what to use instead for the 
> question-marks to ensure that no filter will be used but  the 
> doxygen-parser directly.
>
> Is someone able to help me?
>
> With many thanks,
>                             Eckard Klotz.
>
>

[Doxygen-develop] Callgraph not taking into account of preprocessor defines

[Dennis H. <Den...@pr...>]

Hi,

I'm trying to generate the call graph in the following C code, but it doesn't seem to take into the account the predecessor define.  Consider the following example, in which I see the documentation of func2 generated correctly, but the callgraph shows main -> func1, which is incorrect.

Any idea how to work around this?
Thanks in advance.


test.c:

#include <stdio.h>

#ifdef FUNC1
/*!
@par func1
*/
void func1(int test)
{
        printf("Called func1\n");
}
#else
/*!
@par func2
*/
void func2(int test)
{
        printf("Called func2\n");
}
#endif

int main() {

#ifdef FUNC1
        func1(0);
#else
        func2(0);
#endif

        return 0;
}

--
Dennis Hui
Software Developer (SR) | Presagis

T. +1 514 341.3874 X4257 F. +1 514 341.8018



AVIS DE CONFIDENTIALIT? - CONFIDENTIALITY NOTICE

Ce courriel est destin? exclusivement au(x) destinataire(s) mentionn?(s) ci-dessus et peut contenir de l'information privil?gi?e, confidentielle et/ou dispens?e de divulgation aux termes des lois applicables. Si vous avez re?u ce message par erreur ou s'il ne vous est pas destin?, veuillez le mentionner imm?diatement ? l'exp?diteur, effacer ce courriel sans en faire de copie et ne pas divulguer ou transmettre ? quiconque ce courriel.



This e-mail message is intended only for the above named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this message in error or are not the named recipient(s), please immediately notify the sender, delete this e-mail message without making a copy and do not disclose or relay this e-mail message to anyone.

Re: [Doxygen-develop] Patch for generating correct call/caller graphs and function references if conditional compilation is used

[dhui <den...@pr...>]

Hi Martin,

I'm hitting the same problem but with C.  I tried to download your patch but
have no success getting it.  Can you post the patch again?

This callgraph "bug" seems pretty basic.  I wonder why nobody else has
posted this problem?

Thanks,
Dennis



--
View this message in context: http://doxygen.10944.n7.nabble.com/Patch-for-generating-correct-call-caller-graphs-and-function-references-if-conditional-compilation-id-tp5374p5940.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

[Doxygen-develop] Mixed language-project with c-comments and matlab-comments

[<Eck...@t-...>]

Hello Everybody.

For my nassi-shneiderman generator for doxygen 
(https://sourceforge.net/projects/moritz/) I'm working on an interface 
for the programming-language matlab.For a first demo-release I created 
some example-sources which I want to use together with my already 
existing c-based  description of the general function of Moritz to 
create with doxygen a documentation. This means I have some txt-files 
with c-comment blocks (where I have defined *.txt as FILE_PATERNS). This 
c-comment-blocks contain doxygen group- and page-definitions which are 
traditionally used from me as description of the language independent 
parts of the documentation. In addition I have some files which contain 
comment-blocks in the programming-language for what I want to add 
examples.  For python this works very good, since doxygen is already 
able to understand python-files as well as c-files. But since doxygen 
does not know matlab, I have to use a perl-filter for those files. The 
perl-filter itself works well as long as I only use my matlab-files. But 
I'm not able to configure doxygen to use this filter for matlab-files 
only and to use its own build-in c-parser for all other files.

If I use
  INPUT_FILTER = "perl ./folder/subfolder/m2cpp.pl"
all matlab-files will be parsed correctly but the files with the 
c-comments will be ignored.

If I use
  FILTER_PATTERNS = "*.m=perl ./folder/subfolder/m2cpp.pl"
doxygen tells me that the perl-script can not be opened. The c-comment 
files will be analysed but not the matlab-files.

I had the idea to use
  INPUT_FILTER = "perl ./folder/subfolder/m2cpp.pl"
together with
  FILTER_PATTERNS = "*.txt=?????    
to use the perl-fileter as default-filter and to deactivate it for the 
txt-files which contain the c-comment blocks. But I don't know what to 
use instead for the question-marks to ensure that no filter will be used 
but  the doxygen-parser directly.

Is someone able to help me?

With many thanks,
                             Eckard Klotz.

[Doxygen-develop] [PATCH] UNO IDL bugfixes and PREDICTABLE_URLS option

[Michael S. <ms...@re...>]

hello Dimitri,

thanks for merging UNO IDL patches :)

i've had some more time to spend on doxygen this week, and results are
looking quite good now (in LibreOffice feature/doxygen branch).

1. there were still a few bugs, fixed by the attached patch

2. one problem i've had is that we have not only the generated
   per-entity reference documentation but also another form of
   documentation in the form of a large number of Wiki pages, with
   links in both directions.

   the legacy "autodoc" tool has native support for reading a special
   file that essentially contains links into the Wiki that need to be
   inserted into the generated per-entity reference documentation.

   i've played around a bit and found that i could generate an extra
   dummy input file that contains empty definitions, and put the
   Wiki links on them as doxygen comments, and feed that as the last
   input file (to prevent spurious references to generated file)
   and doxygen will combine the docs nicely.

http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/doxygen&id=b3dbf93c5e18b6f31b11f9bcc08a105b2e0d3b10

3. for the other direction there are some issues... the Wiki
   documentation links to the per-entity reference documentation with
   some convenient template like;

   <idl>com.sun.star.ucb.XContentIdentifierFactory</idl>

   to get this to work the target URLs need to be generated
   automatically just from the namespace qualified entity name.

   this required some changes to doxygen, adding a new PREDICTABLE_URLS
   config option, see attached patch.

4. we are currently just a couple weeks away from the LO 4.1 feature
   freeze, and i'd like to merge this into the 4.1 release.... which
   distributions will package... so we would need a release of doxygen
   with all the UNO IDL patches that distros can package as build-dep.
   i'll follow up in a separate mail on this.

regards,
 michael

Re: [Doxygen-develop] Build failure because src/Makefile is not properly parsed (some of the time)

[Hanspeter N. <fi...@sn...>]

On 5/2/2013 6:17 PM, Erik Zeek wrote:
> On Thu, May 2, 2013 at 4:02 PM, Hanspeter Niederstrasser <
> fi...@sn...> wrote:
>
>> After trying to understand the doxygen build system, I can say this:
>>
>> 1) the bad compiler commands come from src/Makefile.libdoxycfg.  In the
>> failed builds, src/Makefile.libdoxycfg is not regenerated by tmake and
>> therefore uses the file that came with the tarball
>>
>> 2) src/Makefile.libdoxycfg is not regenerated because the
>> "Makefile.libdoxycfg" target in src/Makefile is skipped
>>
>> For reasons that we have not been able to figure out, this target is not
>> run about 50% of the time.  This is the log output from a successful run:
>>
>
> What's the difference in the modification times between libdoxycfg.pro  and
> Makefile.libdoxycfg and what is the timing resolution of the file system?
>   Could make think that the Makefiles are newer than the pro files?

Thank you, that was most likely it.  We had to patch out 
"-Wno-invalid-source-encoding" because some older compilers don't like 
it, and doing so moved the Makefile.libdoxycfg timestamp ahead of 
libdoxycfg.pro file.  I've removed the patch for Makefile.libdoxycfg and 
that seems to make Makefile.libdoxycfg regenerate 100% of the time 
(tested 10 times).

Thanks!

Hanspeter

[Doxygen-develop] Doxygen Future

[Peter M. <ped...@gm...>]

1) BUGS
We have to create our own bug tracker for doxygen only..
- this meaans removing and deleting olve bugzilla buugs etc..

-- Feature Requests..
We ahve to look forward and implment..

Issues....
Most of the time its an output
https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen

BUT we need to get away from that and be our won project and bugs,,

ME
- dont like sf.net.. I want a job there please.. to make them mrore dev
friendly..
- and bugzilla is not good for me filing bugs etc..

What so I expect;-)
I expect to file a bug or feature request and get a message back.. somehow
eg dupe or alike or reconginsed.. or oppsie..

So we need to make this more obvious...

Should the future of doxygen be a @bug lisst or @todo list or @wish list ?

We can help with that..

we need to explain a simple markup technique. .using doxyy...... ;-)

[Doxygen-develop] Team with jenkins

[Peter M. <ped...@gm...>]

yo, hi ho..

its off to docs we go
with a bit and a bang with my shit code..

I understand where u come from ...

But I can help..

So first trick is to delegate jobs and build a trustes team..

Dont trust me btw.. trust one of your trusted already...

But delegate as fast as possible..

Get othere to do things for you nad forget the history.. please..

Just whack it into git and then we can all have fun and replace history
later..
Probably a GSOC code for doxygen musueum..


But what I do like is the idea of compiling docs online..
and for that we need a serveers and the latext code..

>>>>>>>>>>>>>>>> Future >>>>>>>
So we need to step up a bit
we already have a docs system for javascript (indeed ;-)
and we got go
and aarduino code
and web of things
<<<<<<<<<<<<<<<
And the only candidate who can make sense outta that..
Si the color designer and the coder..

So Plugins are in..
and imho we need desinger based plugins..

Then we are freeeeeeeeeeee...
we caan design all ou own aapis..
and publish then automaticaly with doxygen..

I no longer need to ponder and look at the code,

============================
Moved to Git
=============================
As soonas we move to git..
We can build automatically the builds for
windows, et all..
That is every commit to master..

This helps downsteam..
Compiling all the code on master is the "done deal" so we expect this to be
a regular monnthly things or not//

<<<<<<<<<<<<<<
Breaking downstream
<<<<<<<<<<<<<<<<<<<<
Instaling doxygen5
well with new parser, some things will break big time..
so we need a simple solution to this problem..

We need some guidanve to some "fix" but i dont think this is possible..
Need new design.. and a cmd line interface to do this..

>>>>>>>>>>>
releases
: We need some system to release software automatically every month or so..
aad push

<<<<
next
>>
Next is the branch of next stuff before it goes into master.......
This is what is expected to be out soon..

>>
to get into next, u need to be having it merged and working and a
branch/fork..


<<

This is the way that the general c++ and core code work..

HOWEVER..
I do not think that the fortran, c or parsers should exist in the core
code..

These need to be plugins and their own..

Style.......................#


How make that nice...

Re: [Doxygen-develop] Build failure because src/Makefile is not properly parsed (some of the time)

[Peter M. <ped...@gm...>]

Whats the source.. u on svn latest right ?

Re: [Doxygen-develop] Build failure because src/Makefile is not properly parsed (some of the time)

[Erik Z. <ze...@ma...>]

On Thu, May 2, 2013 at 4:02 PM, Hanspeter Niederstrasser <
fi...@sn...> wrote:

> After trying to understand the doxygen build system, I can say this:
>
> 1) the bad compiler commands come from src/Makefile.libdoxycfg.  In the
> failed builds, src/Makefile.libdoxycfg is not regenerated by tmake and
> therefore uses the file that came with the tarball
>
> 2) src/Makefile.libdoxycfg is not regenerated because the
> "Makefile.libdoxycfg" target in src/Makefile is skipped
>
> For reasons that we have not been able to figure out, this target is not
> run about 50% of the time.  This is the log output from a successful run:
>

What's the difference in the modification times between libdoxycfg.pro  and
Makefile.libdoxycfg and what is the timing resolution of the file system?
 Could make think that the Makefiles are newer than the pro files?

Does touching the pro files after extracting them force a rebuild of the
Makefiles every time?

Erik

-- 
*************************************************
Erik Zeek
ze...@ma...
*************************************************
Against stupidity the very gods
Themselves contend in vain.
  - Johann Christoph Friedrich von Schiller (1801)
*************************************************

[Doxygen-develop] Build failure because src/Makefile is not properly parsed (some of the time)

[Hanspeter N. <fi...@sn...>]

The Fink project (an OS X package manager) has had a recent rash of 
build failures with doxygen 1.8.3.1 that I've been able to track down to 
src/Makefile not being properly read.  However, we have no idea what the 
actual event that leads to failure is.  The maddening aspect is that the 
build succeeds a little less than half the time, and it is unclear what 
causes one build to properly parse src/Makefile in while another doesn't 
(no change in the build system in between runs).

This is the fatal error, but the cause is earlier in the build (which 
I'll describe further below).

******
c++ -Wl,-search_paths_first -o ../bin/doxygen ../objects/main.o 
-L../lib -L/sw/lib -ldoxygen -ldoxycfg -lqtools ../lib/libmd5.a 
-lpthread -liconv -framework CoreServices
Undefined symbols:
   "_iconv_close", referenced from:
       _portable_iconv_close in libdoxycfg.a(portable_c.o)
      (maybe you meant: _portable_iconv_close)
   "_iconv", referenced from:
       _portable_iconv in libdoxycfg.a(portable_c.o)
      (maybe you meant: _portable_iconv, _portable_iconv_close , 
_portable_iconv_open )
   "_iconv_open", referenced from:
       _portable_iconv_open in libdoxycfg.a(portable_c.o)
      (maybe you meant: _portable_iconv_open)
*****

OS X comes with BSD iconv, which provides the _iconv_* symbols. 
However, the common OS X package managers (Fink, Macports, Homebrew) all 
prefer gnu libiconv (which uses _libiconv_* symbols).  In this case, 
doxygen is trying to link to our gnu libiconv (Fink's prefix is /sw), 
but portable_c.o was accidentally compiled with the system BSD iconv.h.

The compiler line for the miscompiled portable_c.o is this (/usr/local 
doesn't exist, btw):

cc -c -pipe -Wall -W -Wno-deprecated-declarations  -g -fstack-protector 
-I../qtools -I/usr/local/include -o ../objects/portable_c.o portable_c.c

When the build succeeds, the compiler command is:

cc -c -pipe -MD -Wall -W -Wno-deprecated-declarations -O2 -I../qtools 
-I/sw/include -o ../objects/portable_c.o portable_c.c

After trying to understand the doxygen build system, I can say this:

1) the bad compiler commands come from src/Makefile.libdoxycfg.  In the 
failed builds, src/Makefile.libdoxycfg is not regenerated by tmake and 
therefore uses the file that came with the tarball

2) src/Makefile.libdoxycfg is not regenerated because the 
"Makefile.libdoxycfg" target in src/Makefile is skipped

For reasons that we have not been able to figure out, this target is not 
run about 50% of the time.  This is the log output from a successful run:

******
env 
TMAKEPATH=/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/lib/macosx-c++ 
/usr/bin/perl 
/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/bin/tmake 
libdoxygen.pro >Makefile.libdoxygen
env 
TMAKEPATH=/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/lib/macosx-c++ 
/usr/bin/perl 
/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/bin/tmake 
libdoxycfg.pro >Makefile.libdoxycfg
env 
TMAKEPATH=/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/lib/macosx-c++ 
/usr/bin/perl 
/sw/build.build/doxygen-1.8.3.1-1/doxygen-1.8.3.1/tmake/bin/tmake 
doxygen.pro >Makefile.doxygen
******

In failed runs, the 2nd line from this output is missing and 
Makefile.libdoxycfg is never regenerated.  So something is 
non-deterministically causing that target to be skipped.  The build is 
run in a clean environment every time and we are using -j1 to avoid 
possible race conditions.

Do you have any ideas as to what might be causing the failure to 
regenerate Makefile.libdoxycfg?  We have a temporary fix, but it would 
be nice to understand the underlying cause for this bug.  Thanks,

Hanspeter

ps.  Makefile.libmd5 also suffers from this indeterminate regeneration 
but it doesn't mix headers so there's no direct failure.

Re: [Doxygen-develop] GIT

[Dimitri v. H. <do...@gm...>]

Hi Peter,

I see you are very eager to help (thanks for that), but I also need to adjust my way of working 
and scripts I build around that, so please be patient. I think it is good if I do the migration
myself and can check and validate that everything is working (and put in my latest set of changes).

I check out your tip of turning doxygen on github into an organisation.

Regards,
  Dimitri

On Apr 27, 2013, at 2:32 , Peter Morgan <ped...@gm...> wrote:

> Am looking more into this, but again dont want to waste time..
> 
> But.. if the move to github.. (or any git hosting).. in gitlab...
> then 
> we need to migrate..
> I can help with that as done this before.. once on a project with 5 devs..
> ie svn to git migration..
> 
> http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
> 
> ###########
> Problems
> ##########'#
> Authors who have identities..
> but there are ways around this.. but its complex.. and easier with new identities and matching later..
> 
> Maintaining backward svn and sf.net
> We can push that another way, by making every commit to master,
> thereby "commit" to trunk as sf.net if needed...
> I am still an advocate for svn as its don't download the "whole history, instead just changes" and this is good downstream..
> So we can make it mix both ways..later...
> 
> Do make it automated.. though..
> 
> We need to use a build farm.. eg Jenkins
> 
> RedHat are still testing their openshift platform
> and got a version running here
> https://doxygen-pedromorgan.rhcloud.com
> login=doxygen
> pass=h2o
> 
> and thats a couple of job that poll the repos,
> pull source
> check for changes
> and recompile the source on a remote machine.. which is mine atmo
> but any app can be one..
> 
> We also build rpm,s etc same way
> and update website..
> 
> So that is the way to go imho, and the way a few other projects go..
> 
> Also..for dimirti..
> with github.com.. 
> u can trun doxygen from an user into an "organisation". .which is a good idea...
> This means u can then add admins etc and allow others to manage parts etc..
> 
> anyway.. 
> Will start a svn to git migration id u give the "nod" to go ahead.. 
> as I got the stuff on machine and been there done that so it should be ok..
> 
> Pete
> 
> 
> On 26 April 2013 23:58, Peter Morgan <ped...@gm...> wrote:
> Hi all,
> 
> This is following on from a  previous  discussion about git...
> 
> I see that 
> https://github.com/doxygen
> is there and its dimitri etc..
> 
> But also a search for doxygen shows so many mirrors.. etc etc all outta date..
> 
> So is there a possibility to at least create the github.com version as official..
> so we can all fork..
> 
> There are tools to import and if help is required then am around 2 assist ...
> But generally speakin i would expect a 
> "master" - branch which is stable 
> "next" - which is the next dev flavour (like trunk/)
> 
> and all the tags etc should import with 
> git svn checkout..
> 
> There are so many clones though... we'd save github/aws a lot of disk space..... maybe
> https://github.com/search?q=doxygen&ref=cmdform
> 
> regards
> Pete
> 
> 
> 

Re: [Doxygen-develop] (no subject)

[Peter M. <ped...@gm...>]

>
>
>
> I should have specified - I can definitely compile successfully from
> source, so this request comes from the following motivations:
>
>    - I am creating build configurations so a machine can have a full
>    development environment installed (including doxygen) from scratch in an
>    automated way, for both build slaves and for new developers on my project
>    - automating subsequent upgrades on these machines is much easier if I
>    can use the system package manager
>
> I've never set up a PPA before, and do not regularly develop on a Linux
> machine, so I was holding out some hope that this had been done and I just
> couldn't find info about it :) But I may just have to dive in and try it
> myself.
>
>
> I've been looking at installing jenkins on openshift to "build" doxygen
remotely..
deb package et all

pete

Re: [Doxygen-develop] (no subject)

[Liam S. <ls...@gm...>]

Hi Vaclav - thanks for your response.

I should have specified - I can definitely compile successfully from
source, so this request comes from the following motivations:

   - I am creating build configurations so a machine can have a full
   development environment installed (including doxygen) from scratch in an
   automated way, for both build slaves and for new developers on my project
   - automating subsequent upgrades on these machines is much easier if I
   can use the system package manager

I've never set up a PPA before, and do not regularly develop on a Linux
machine, so I was holding out some hope that this had been done and I just
couldn't find info about it :) But I may just have to dive in and try it
myself.

Liam


On Tue, Apr 30, 2013 at 2:33 AM, Vaclav Petras <wen...@gm...> wrote:

> On 25 April 2013 17:30, Liam Staskawicz <ls...@gm...> wrote:
> > Hi,
> >
> > Pardon for the cross post from doxygen-users, but does anybody know of an
> > existing PPA that packages recent versions of Doxygen for older Ubuntu
> > releases? I'm most interested in getting 1.8.3 onto x86 and x64 machines
> > running precise.
> >
>
> Hi, I would suggest you to just to download source code and compile.
> You can either download tarball or use svn, in the last months I'm
> using the latest version from svn and it's working properly and if not
> you will help to discover bug. I have no problems with compilation
> since I have all the required libraries anyway. Only problem is that
> you need to add the new doxygen bin directory to PATH and update
> manually. I'm using Ubuntu 10.04 (64bit) and 12.04 (32bit). All the
> information you need is here:
>
> http://www.stack.nl/~dimitri/doxygen/download.html
>
> Vaclav
>
> > Thanks for any tips.
> >
> > Liam
> >
> >
> ------------------------------------------------------------------------------
> > Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring
> service
> > that delivers powerful full stack analytics. Optimize and monitor your
> > browser, app, & servers with just a few lines of code. Try New Relic
> > and get this awesome Nerd Life shirt!
> http://p.sf.net/sfu/newrelic_d2d_apr
> > _______________________________________________
> > Doxygen-develop mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> >
>

Re: [Doxygen-develop] (no subject)

[Vaclav P. <wen...@gm...>]

On 25 April 2013 17:30, Liam Staskawicz <ls...@gm...> wrote:
> Hi,
>
> Pardon for the cross post from doxygen-users, but does anybody know of an
> existing PPA that packages recent versions of Doxygen for older Ubuntu
> releases? I'm most interested in getting 1.8.3 onto x86 and x64 machines
> running precise.
>

Hi, I would suggest you to just to download source code and compile.
You can either download tarball or use svn, in the last months I'm
using the latest version from svn and it's working properly and if not
you will help to discover bug. I have no problems with compilation
since I have all the required libraries anyway. Only problem is that
you need to add the new doxygen bin directory to PATH and update
manually. I'm using Ubuntu 10.04 (64bit) and 12.04 (32bit). All the
information you need is here:

http://www.stack.nl/~dimitri/doxygen/download.html

Vaclav

> Thanks for any tips.
>
> Liam
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] [PATCH] Minor improvements to citation/bibliography/index output

[Markus G. <mg...@we...>]

Hi,

Please find a patch against the current head of SVN (r845) attached
which slightly improves the output of citations, the bibliography
and the ToC entry of the index. In detail, these are:

  - A citation in now separated by a non-breakable space from the
    preceding text. This is implemented for HTML, LaTeX, man, RTF
    and XML output (to the best of my knowledge; only HTML and
    LaTeX tested).

  - For LaTeX, the entries in the table of contents for the index
    and bibliography should use the "top-level" sectional unit used
    for the document itself. That is, 'section' if COMPACT_LATEX=yes
    and 'chapter' otherwise.
    (The current default, 'part', is set in a larger font which looks
    quite ugly.)

  - For LaTeX, the references section is called 'Bibliography' when
    OUTPUT_LANGUAGE=English. However, the ToC entry uses the string
    from the translator class, which was 'Bibliographic References'.
    For consistency, I changed it to 'Bibliography'.

Hope this makes sense.

Thanks,
Markus