Build System for OpenPetra: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
== NAnt ==
== NAnt ==
The build system is done with NAnt. Some functions are written directly in C# in the build files, but we also have plugins in charp/ICT/PetraTools/NAntTasks.
The build system is done with NAnt. Some functions are written directly in C# in the build files, but we also have plugins in inc/nanttasks.


== Plugins Ict.Tools.NAntTasks.dll ==
== Plugins Ict.Tools.NAntTasks.dll ==
Line 6: Line 6:
* Mysql plugin: run sql statements against MySQL
* Mysql plugin: run sql statements against MySQL
* DotNetExec plugin for running other Petra Tools
* DotNetExec plugin for running other Petra Tools
* CsDepend plugin: Calculate the dependencies between the C# files and generate nant files


== Configuration files ==
== Configuration files ==
* currently there are 3 sample OpenPetra.build.config files. The user has to pick one, copy it to OpenPetra.build.config, and modify it. *.config files are not committed to the VCS.
* for certain setups, the user can create a OpenPetra.build.config.my, and commit it to VCS. A local OpenPetra.build.config file still has higher priority than the .my file


== Generating project and solution files ==
You could add a configuration file called ''OpenPetra.build.config'' parallel to the OpenPetra.build file for setting properties, which differ to the standard value. All possible properties could be seen in ''inc/nant/OpenPetra.common.xml''.
* The goal is to remove the project (csproj) and solution (sln) files from VCS, and to generate those files.
 
* This way we can support several formats of project files, and we won't need <code>nant fixProjectFiles</code> anymore.
For example using ''postgresql'' instead of ''SQLite'', you would use:
* We also want to be able to generate a solution for the client and for the server, which has all project files from Ict.Common and Ict.Petra.Shared included, so that debugging is possible through all dlls.
<code><?xml version="1.0"?>
* We also won't need <code>nant addProject</code> anymore, which was using templates in csharp/ICT/PetraTools/Templates/ProjectFiles.
<project name="OpenPetra" default="help">
* The contained cs files of a project need to be picked by convention, ie. all cs files in a directory belong to the project for that dll.
    <property name="DBMS.Type" value="postgresql"/>
** Question: are the paths unique and correct, so that we can calculate the project/dll name by convention?
    <property name="DBMS.Password" value="hm5MMxmjthwalVK2PXwN"/>
* The references to other dlls need to be picked up from the using clauses.
</project>
* We will need to add some PetraTools/*.exe and Ict.Common*.dlls to the VCS, otherwise it will be difficult to generate the project files.
</code>
 
Most of the time you need this file for adding database information or using programs, which are not installed in the typical location or differ in the version.

Revision as of 16:19, 28 February 2011

NAnt

The build system is done with NAnt. Some functions are written directly in C# in the build files, but we also have plugins in inc/nanttasks.

Plugins Ict.Tools.NAntTasks.dll

  • Postgresql plugin: run sql statements against PostgreSQL
  • Mysql plugin: run sql statements against MySQL
  • DotNetExec plugin for running other Petra Tools
  • CsDepend plugin: Calculate the dependencies between the C# files and generate nant files

Configuration files

You could add a configuration file called OpenPetra.build.config parallel to the OpenPetra.build file for setting properties, which differ to the standard value. All possible properties could be seen in inc/nant/OpenPetra.common.xml.

For example using postgresql instead of SQLite, you would use: <?xml version="1.0"?> <project name="OpenPetra" default="help">

   <property name="DBMS.Type" value="postgresql"/>
   <property name="DBMS.Password" value="hm5MMxmjthwalVK2PXwN"/>

</project>

Most of the time you need this file for adding database information or using programs, which are not installed in the typical location or differ in the version.