On Thu, Jun 6, 2013 at 3:39 PM, Dimitri van Heesch <[email protected]> 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-process the the output of flex with a perl filter before writing it > to disk > - I create configoption.cpp from config.xml via a Python script > (most of the 'special stuff' can be found in src/libdoxygen.t and > src/libdoxycfg.t, to tmake > config files). > - a src/settings.h is to be generate with USE_SQLITE3 and USE_LIBCLANG set > depending > on --with-sqlite3 and --with-libclang > - a src/version.cpp should be generated with the version of doxygen (current > stored in the > configure file, but that could better be another file).
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! ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/doxygen-develop
