similar to: [LLVMdev] Doxygen: enable autobrief?

Getting rid of all the distracting \brief comment markers in our header files would be great! Note that we will also need to update our coding standards to no longer encourage them then. -- adrian > On May 3, 2015, at 9:08 PM, Justin Bogner <mail at justinbogner.com> wrote: > > Matthias Braun <matze at braunis.de> writes: >> We just had some discussion in the IRC

I am all for not having to add \brief. The more readable the comments are for someone not using doxygen the better. On May 8, 2015 2:06 PM, "Matthias Braun" <matze at braunis.de> wrote: > So far I've heard no objections, I'll wait a few more days and then change > the doxygen configuration and the recommendations in the coding standards. > I do not plan to remove

So, I'd love to not have to write '\brief' but that's not what this gives us sadly. The behavior of autobrief is that the brief snippet stops at the first '.' in the text. It doesn't matter if that '.' is part of code or anything else. The behavior of the '\brief' command is that the paragraph it marks is the brief comment, and the detailed one starts

It seems the mail you are referring to never made the list: it's not in the archives and not in my mailbox. Take a look here: http://lists.xiph.org/pipermail/flac-dev/2012-December/thread.html It's probably still waiting for moderation. On 07-01-13 17:07, Olivier BLIN wrote: > On 29/12/2012 00:06, Olivier Blin wrote: >> When building outside of the source tree, the Doxyfile

One thing that would be handy for driver developers (or for myself, at the very least) would be having some API documentation for the core NUT functions. Here is an example of Doxygen's output: http://www.ghz.cc/~clepple/libhid/doc/html/hid_8h.html The two main categories of API documentation that I see are the internal NUT functions needed for writing drivers, etc., and the external

hey, so I'm writing in cpp. the documentation says that TheModule -> getDataLayout should return const DataLayout, but instead it is returning std::string. I require it to return DataLayout, as I generalize my function pass manager to accept the DataLayout constant as an argument, it being the only thing in common amongst both the ExecutionEngine and the Module class. Any pointers to

Includes - A make debug target that disables optimizations and enables assertions, - Proper ./configure switches for the optional features, - A configuration summary, - libtool versioning information, - Visibility and warning flags, - API documentation, and - Support for out-of-tree builds. Signed-off-by: Diego Elio Petten? <flameeyes at flameeyes.eu> --- .gitignore | 29 +++++

On Nov 24, 2012, at 1:02 AM, Tinco Andringa <mail at tinco.nl> wrote: > Hi, > > I think it's an awesome idea to make sure all names are logical. It is > an essential feature of a good API to have logical naming :) > >> I really dislike that all the files and classes in the MC library >> start with MC. This is c++, not c :( > > On a similar note, all

When building outside of the source tree, the Doxyfile needs to be generated in the build tree and should point to the proper paths for include directories and html footer. The generated api files to install should also be taken from the build tree instead of the source tree. --- configure.ac | 1 + doc/Doxyfile | 1220 --------------------------------------------------

When building outside of the source tree, the Doxyfile needs to be generated in the build tree and should point to the proper paths for include directories and html footer. The generated api files to install should also be taken from the build tree instead of the source tree. --- configure.ac | 1 + doc/Doxyfile | 1220 --------------------------------------------------

Chris Lattner wrote: >> I tried generating the docs myself ... doxygen simply refuses to >> create pages for classes defined in anonymous namespaces in cpp files. >> I enabled options such as EXTRACT_ALL, EXTRACT_PRIVATE and >> EXTRACT_LOCAL, but no luck. How is the publicly available >> documentation generated? > > They are generated from the Makefile in

On Tue, 15 Nov 2005, Sameer D. Sahasrabuddhe wrote: > The docs available on illuvium.com are different from the one's present in > the doxygen tarball on the same page ... can the tarball be generated from > the same docs as the browseable version? I considered crawling the > illuvium.com site, but it would be better to simply have a tarball available. Agreed. I have been

Hi all! I'm currently working with Compiz and as part of that I'm trying to create more developer documentation, as I think that's important in inviting both new explorers and bug patches to the project. I've started an overview document to go in addition to any existing code examples. It's currently available at http://iki.fi/Tuukka/2006/summercode/wiki/CompizTechOverview

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

Hi, The docs available on illuvium.com are different from the one's present in the doxygen tarball on the same page ... can the tarball be generated from the same docs as the browseable version? I considered crawling the illuvium.com site, but it would be better to simply have a tarball available. I tried generating the docs myself ... doxygen simply refuses to create pages for classes

Hi there. What about repainting the top-level bike-shed - the build system itself? I've got a framework called "v3c" in SourceForge that has a top-level makefile. From that makefile you can just do "make" to build it with debug information, "make release" for a release build, "make -j7 distcheck" to throw a few cores at the build, "make -j7 git

Would it be helpful to be able to use Doxygen on TableGen .td files?

Hi All, I am going to clean up those doxygen links on LLVM Programmer’s Manual [1], some are lost and some are too old. However, I am confused on which doxygen link I should pick up. I see there are mutiple links exist on LLVM web site for LLVM classes. Take class Statistic as example, there are: - http://llvm.org/doxygen/Statistic_8h-source.html (the oldest one, I believe it's

Hi all, I'm having a bit of trouble with the online doxygen documentation. As far is I know, it should reflect current svn trunk. However, it seems out of date. For example, the ExtractValueInst [1] is not a UnaryInstruction yet and still takes Value* as indices. To add to the confusing, the mainpage [2] says it is documentation version "2.1svn" which seems even more weird. What

> I'm having a bit of trouble with the online doxygen documentation. As far is I > know, it should reflect current svn trunk. However, it seems out of date. For > example, the ExtractValueInst [1] is not a UnaryInstruction yet and still > takes Value* as indices. > > To add to the confusing, the mainpage [2] says it is documentation version > "2.1svn" which seems