Giter Site home page Giter Site logo

cmake-basis / basis Goto Github PK

View Code? Open in Web Editor NEW
48.0 48.0 10.0 7.51 MB

CMake BASIS makes it easy to create sharable software and libraries that work together. This is accomplished by combining and documenting some of the best practices and utilities available. This project supplies a fully integrated suite of functionality to make the whole process seamless!

Home Page: https://cmake-basis.github.io

License: Other

CMake 26.90% Python 16.78% CSS 0.44% HTML 0.72% Perl 5.12% C++ 44.63% C 0.05% Shell 4.33% MATLAB 0.02% Batchfile 0.02% JavaScript 0.75% Java 0.21% Raku 0.03%
cmake cmake-basis project-creation project-template

basis's People

Contributors

ahundt avatar aschuh-hf avatar cathaysia avatar geohussain avatar ghisvail avatar schuhschuh avatar wittenbe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

basis's Issues

[CLOSED] Sync Doxygen To-Do list with Redmine/ChiliProject project issues

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#8


Doxygen generates a To-Do page from @todo tags found in the source code documentation.

This feature would add a new issue for each such to-do item if no corresponding issue was found. Otherwise, it does not add another issue. If a to-do item was removed from the Doxygen To-Do page by removing the @todo tag from the source code, the issue related to it shall be set to either resolved or closed. There must be a reliable way to connect issues with items on Doxygen's To-Do page, otherwise it will be impossible to notice that such issue was resolved.

The test if an open issue corresponds to a resolved to-do item must be run automatically, for example, once every day or whenever a change of the Doxygen documentation on disk is recognized using certain Unix filesystem events. Other possibilities to implement this must be investigated.
Reporter: Andreas Schuh
Begin: 2012-01-09
Completed: 0

[CLOSED] Integrate argh command-line parsing library for Python

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#30


Before, make sure that the decision for argh is a good one!

Alternatives are the python-gflags library and others. The use of the argh library should, however, be more intuitive.

In any case, provide a command-line parsing solution for Python.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-13
Completed: 0

[CLOSED] Recover template files in .basis/ directory if missing

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#47


The basisproject tool uses three-way file merge to merge changes of the project files with those of the possibly newer template files. Therefore, it needs to keep a copy of the original template file in the .basis/ subdirectory of the project. If these files are missing, the basisproject tool should try to recover them if necessary, for example, by simply assuming that the current template file has been the original template file. This would not give the right merge, but at least the update should be feasible for future changes of the template again.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-02-09
Completed: 0

[CLOSED] Add make_directory() function to path.h module

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#32


The creation of directories is often needed before output files can be written by a program. In C/C++, this is not trivial to do in a platform independent manner. Hence, add this basic functionality to the path.h module of BASIS.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-17
Completed: 0

[CLOSED] Write XSLT based tool which converts --helpxml output to Markdown

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#7


This tool would then be used by BASIS to automatically add the full help of the executables as appendix to the user manual. The help of auxiliary executables, on the other side, shall be added to the developer manual (Wiki?).

Alternatively, reStructuredText may be used as output format.
Reporter: Andreas Schuh
Begin: 2012-01-09
Completed: 0

[CLOSED] Redmine plugin which renders documentation written in lightweight markup

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#6


If we decide to implement either Redmine or ChiliProject at SBIA for software project management, consider the implementation of a Redmine/ChiliProject plugin which uses the documentation files of the project in the repository to render HTML pages similar to the gh-pages of GitHub. This feature would be similar to editing the Wiki pages locally and committing them to the repository in order to update the content of the project documentation in Redmine/ChiliProject.
Reporter: Andreas Schuh
Begin: 2012-01-08
Completed: 0

[CLOSED] Extend documentation of basisproject tool

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#48


The how-to which is part of the Doxygen generated documentation should be extended to include:

  • Details on how to create a project with modules.
  • Information on how to resolve merge conflicts.
  • Have a reference to the documentation which describes the purpose of the template files.
    Reporter: Andreas Schuh
    Assigned to: Andreas Schuh
    Begin: 2012-02-10
    Completed: 0

[CLOSED] Public header files of modules are configured using the CMake variables defined at top-level only

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#38


When public header files are configured, the CMake variables as defined at the beginning of the top-level project are dumped and considered only. Instead, when a module's public headers are configured, the CMake variables which are defined after the import of its dependencies and the module's Settings.cmake file should also be considered. This requires the call of basis_configure_public_headers() in each module's basis_project_impl().
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-24
Completed: 0

Use domains in Doxygen filters to distinguish objects from different languages

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#31


Similar to the domains concept of Sphinx, the documentation generator for Python, use domains, i.e., top-level namespaces, for different programming languages such that objects implemented in different languages with the same name can be distinguished. The default domain for Doxygen should be clearly C++.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-13
Completed: 0

[CLOSED] Move Coverage/MemCheck build configuration to basistest CTest script

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#36


According to a comment of David Cole (6/3/2011) on the CMake mailing list, the compiler flags for coverage builds should be put in the CTest script rather than the CMakeLists.txt files. In this case, consider to change the basistest CTest script to avoid submission to the dashboard to allow developers to still only get local coverage results w/o submission to the dashboard.

This should apply similar to the MemCheck build configuration, which will also allow to choose the best settings for the actually used memory checker.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-23
Completed: 0

[CLOSED] MATLAB Compiler targets fail due to licenses already in use

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#35


Especially at the lab where we do have only one license for the MATLAB Compiler, when more than one build is running at the same time, only one may succeed and the others fail because the license is occupied by one build, even if only for a short time.

To avoid the failure of the other build jobs, modify the custom build target to sleep for a short time and then retry building the MCC target. The number of retries shall be configurable via a cached advanced CMake variable.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-22
Completed: 0

Fix memory leaks caused by C++ command-line parsing library

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#16


These memory leaks are reported by valgrind for the tests parseargs-help, parseargs-helpshort, and parseargs-version, i.e., where the execution is prematurely terminated by TCLAP.

==18575== 8 bytes in 1 blocks are still reachable in loss record 1 of 108
==18575== at 0x4A0695E: operator new(unsigned long) (vg_replace_malloc.c:220)
==18575== by 0x418983: sbia::basis::CmdLine::setup() (in /sbia/comp_space/swtest/testing/Nightly/sbia-cluster-centos5/BASIS-Linux/trunk/Testing/bin/parseargs)
==18575== by 0x419CAF: sbia::basis::CmdLine::CmdLine(std::string const&, std::string const&, std::string const&, std::vector<std::string, std::allocatorstd::string > const&, std::string const&, std::string const&, std::string const&, std::string const&) (in /sbia/comp_space/swtest/testing/Nightly/sbia-cluster-centos5/BASIS-Linux/trunk/Testing/bin/parseargs)
==18575== by 0x408931: main (in /sbia/comp_space/swtest/testing/Nightly/sbia-cluster-centos5/BASIS-Linux/trunk/Testing/bin/parseargs)
==18575==
Reporter: Site Admin
Begin: 2012-01-11
Completed: 0

[CLOSED] Write FindBoost.cmake module which adds Boost_DIR to CMake cache

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#21


The FindBoost.cmake module which comes with CMake sets the advanced Boost_INCLUDE_DIR and Boost_LIBRARY_DIR variables. However, for the user it would be helpful to show the variable Boost_DIR which is set to the installation prefix of Boost to the CMake cache such that it shows up in the GUI. See FindMOSEK.cmake module of BASIS for reference.
Reporter: Andreas Schuh
Begin: 2012-01-11
Completed: 0

[CLOSED] Generator expressions not fully supported by basis_add_test()

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#42


The basis_add_test() function should understand generator expressions such as $<TARGET_FILE:tgtname> (see documentation of "add_test":http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test). As basis_add_test() is using add_test() under the hood, it probably already supports these generator expressions. However, the target names given as argument need to be mapped to target UIDs as used by BASIS.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-25
Completed: 0

Finish implementation of C++ command-line parsing library

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:57 GMT
Originally opened as cmake-basis/legacy#29


The C++ command-line parsing library (based on "TCLAP":http://tclap.sourceforge.net/) is yet only partly implemented.

One of the major features missing is the output of an XML description of the command-line interface.

It must further be revised if all common argument types are supported properly, including an argument with a flag which can either have an argument value or not. For example, "--bias-correct[=suffix]" as used by MICO 1.0.

The use of the library for common programs should be as intuitive as possible.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-13
Completed: 0

[CLOSED] Fix layout of embedded Doxygen documentation

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#9


When embedding the Doxygen documentation using the @Embedded@ plugin of Redmine, the layout of the Doxygen pages is a bit messed up. In particular, lists of hierarchies and the sub-menu items at the top of some pages are not displayed with the right layout.

  • Add the ability to specify an additional CSS include file to the header of embedded documents.
  • Write a CSS file which fixes the layout of the embedded Doxygen pages.
    Reporter: Andreas Schuh
    Begin: 2012-01-09
    Completed: 0

Option to build only the tests of particular modules

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#22


It can be helpful for debugging only the tests of a particular module if one could enable only the tests of selected modules, not necessarily all enabled modules. Here, the BUILD_TESTING option would act as a "BUILD_ALL_TESTS" option similar to the BUILD_ALL_MODULES. Then, there could be a TEST_ option for each module.
Reporter: Andreas Schuh
Begin: 2012-01-11
Completed: 0

[CLOSED] Deprecated public header files are not removed from binary include directory

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#4


After a module was enabled, it's public header files are copied to the binary include directory. Then, when the module is disabled again, these public header files are not removed and hence still available in the build tree, though they should no longer be there.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-06
Completed: 0

Submit summary of basistest CTest script arguments as test notes to dashboard

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:58 GMT
Originally opened as cmake-basis/legacy#37


The CTEST_NOTES_FILES variable gives the ability to attach notes to the test result submissions. Of interest may be in particular the details required to re-run the tests with the very same configuration. Therefore, a notes file with the arguments to the basistest CTest script could be helpful.
Reporter: Andreas Schuh
Begin: 2012-01-23
Completed: 0

Support environment setup before test execution

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#18


A BASIS project which another BASIS project depends on shall be tested before the other project. Such dependencies are defined in the BasisProject.cmake file. What about making the testing master a bit smarter and have it analyze such dependencies. It can then execute the jobs in order. On the other side, which tests at a particular moment to execute depends also on the current test schedule, i.e., the minimum time that has to pass before the next test job execution. Therefore this approach might be not applicable and the solution implemented as response to #15 might be sufficient.

Other dependencies to deal with are external packages such as Boost, ITK,... in general all packages which are not tested automatically. In this case, the testing master could call a user supplied program with the name of the package and version as arguments. It is then in the responsibility of this script to setup the environment properly. At our lab, this would be the "module load" commands. This would further allow a test to use a different version of a package then the most recent one which has been installed after the last successful test of that package (see #15).

Alternatively (or optionally) add --testcmd option to configuration file which overwrites the default test command given on the command line. This way, it is possible to have for some tests a different test command, e.g., a script that sets up the environment and then executes the default test command. Or, only have a script for the setup of the environment which gets sourced (?). Keep in mind, though, that the testing should also be possible on Windows in the future.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-11
Completed: 0

[CLOSED] Dependencies of automated tests are not considered by basistest-master

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#15


The basistest-mater script which manages the execution of the automated tests of BASIS projects does not consider the dependencies among the projects which are tested periodically.

How can the dependencies be considered for the automated testing?
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-10
Completed: 0

Web page and user manual generation from lightweight markup

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#5


At the moment, BASIS supports the addition of pages to the API documentation generated by Doxygen by placing @.dox@ files in the @doc/@ directory. However, Doxygen is already older and the syntax is not as intuitive and powerful as lightweight markup languages such as in particular "Markdown":http://daringfireball.net/projects/markdown/ and "reStructuredText":http://docutils.sourceforge.net/rst.html.

I propose the following feature. Documentation files in the @doc/@ directory in the Markdown format shall be converted to reStructuredText as the Markdown is easier, but less powerful than reStructuredText. On the other side, as long as Markdown is enough for a developer, they may not need to use the a bit more complicated reStructuredText markup at all.

  • Files which are in the @doc/user/@ directory shall be converted to a user manual in PDF format.
  • Files which are in the @doc/page/@ directory shall be converted to a project web page in HTML.

It shall be possible to easily link the user manual from the project page, maybe even done entirely automatic. The project page can then be uploaded either to our own public web server or a project page on SourceForge (or others). This upload shall be supported by a build target generated by BASIS which can be configured by the developer. Care must be taken regarding authentication at the server, though. This shall be covered by a separate feature request.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-07
Completed: 0

[CLOSED] Allow project developers to disable the copying of public header files

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:56 GMT
Originally opened as cmake-basis/legacy#3


Here the excerpt from the discussion with Luke (his comments are quoted here) regarding this feature on the "SBIA eLog":https://sbia-infr-vweb.uphs.upenn.edu/elog/Bug+Tracking+and+Feature+Requests+for+Development+Projects/89:

Andreas Schuh replied on Tue Jan 3 11:44:24 2012

  1. this one is somewhat minor. Over break I did an svn update on my project then tried to build it. gcc gave me
    the line number and file of the error, I grabbed the filepath from the error message and fixed the problem
    recompiled and everything was fine. The next day i was working on the same project and the error was suddenly
    back, because I had been editing the file in the build tree not the src tree. This is somewhat minor as if i had
    been really thinking I would have noticed it, however it is somewhat annoying particularly for someone who
    doesn't know the project.

I understand this can happen, but this is common for all files in CMake that get configured into the build tree. Of course, when the original file has the
.in suffix and actually changes, it would be more obvious. Still it would not prevent this mistake from happening other than putting a comment at the
top of a .in file stating that this file was generated from a .in file... certainly we don't want to put this comment in a .h file which actually didn't change
and was copied only, though.

  1. Module dependency: When you turn of a module, that modules header files remain in the build include, meaning
    that if you've build a module once in a build tree its files are there. this causes some issue with sorting out
    module dependencies. this is also confusing as all the file end up in the final include path
    sbia/prjName/header.h etc.

That is on my to-do list already, to remove the deprecated header files from the build tree again.

  1. code coverage: the coverage reports of cdash are linked to the headerfiles in the build tree. thus the
    filenames have no information about what module they are in making finding the file without knowledge of the
    project abit more difficult.

Both, 1) and 3) require a clear understanding of what happens to the public header files in the include/ directory. Once more familiar with BASIS and
given that it is documented and these issues are highlighted in the documentation of BASIS, it should be more obvious.

One way to separate the CDash submissions by module could be to use the subproject feature and the LABELS properties as ITK 4 is doing it on their
Modular Dashboard [1]. Not sure if the support for this by CDash is already matured enough.

Another possibility is to use include paths such as include/sbia/// in the build tree. To get this, you would set the CMake variable
BASIS_USE_MODULE_NAMESPACES to TRUE (see config/Settings.cmake file of the HardiTk).

Overall, I am not feeling to happy about "configuring", i.e., copying, all the header files to the build tree just to have the include path set during
configure time of the project, i.e., to turn include/ into include/sbia//, for example. For files which indeed need to be configured as they use
CMake variables in them and thus use the .in suffix, this is fine and part of the contract with BASIS regarding the meaning of the .in suffix. The nice
thing about it is, that in the project source tree, you don't need to have the as well annoying subdirectory structure include/sbia//. As we
talked about it earlier, there is absolutely no better way than having such include path with only the include/ being in the include search path to avoid
a dependency problem regarding the include statements. In case of the modules, it is even better to not have the subdirectory structure as part of the
module's source tree. If you think about the module as a separate project and would indeed build this module separately, the header files end up in
include/sbia// instead, as now the module is the project. On the other side, even though technically possible, the thing about modules is
that they are tightly coupled to the project they belong to. For the rather loose coupling of projects, we will use the super-build concept. So I guess it
is fine to have a path such as modules/HardiCommon/include/harditk/, i.e., one which includes the name of the project the module belongs to.

All that said, what do you think about having a BASIS CMake variable which can be set in you project's config/Settings.cmake file and is used to specify
which of these implementations a project wants to make use of ? Hence, another way to configure BASIS. For example, let the project developer set
BASIS_USE_SOURCE_INCLUDE_DIRS to either TRUE (no copying of header files to the build tree that don't have the .in suffix) or FALSE (the current
behavior). This would also enable a project to define it's own non-standard include path (although this would violate the standard, but could still be
enforced by checking the path of each header file in the source include/ directory and throwing an error if the standard of include/sbia// is
violated).

[1] http://www.vtk.org/Wiki/ITK_Release_4/Modularization/Modular_Dashboard
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-06
Completed: 0

Implement super-build of BASIS projects

Issue by schuhschuh
Saturday Nov 09, 2013 at 17:57 GMT
Originally opened as cmake-basis/legacy#28


Similar to the modules of a BASIS project, should it be possible to package several BASIS projects together and build them in one step using the super-build concept using the ExternalProject.cmake module. The implementation of this super-build shall support the following:

  • If the an archive file or a subdirectory with a package's sources is included with the package, use it if not otherwise specified by the user.
  • Otherwise, try to find a system installation of the package, in particular if the USE_SYSTEM_ option is set to ON.
  • If a package was neither included with the package nor found in the system, download it if a download URL has been specified by the package provider.

In particular, at SBIA the download URLs will point to the lab's web server. This base URL of such downloads shall be the default used by BASIS.
Reporter: Andreas Schuh
Assigned to: Andreas Schuh
Begin: 2012-01-12
Completed: 0

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.