- 1 Developing Gestinux
- 1.1 Tests
- 1.2 Translation
- 1.3 Documentation
- 1.4 Programmation
- 1.5 Packaging and OS specific informations
- 1.6 Database
Gestinux is an open source software and anyone can help to its development.
Some guidelines for project maintenance follow, which can be discussed in the development forum.
Gestinux must work in various combinations of environments, databases, and languages. It would be useful to have referent testers in each of these different possible combinations, particularly during release-candidates publishing.
To test safely, especially non stable versions, it is better to make a copy of a production database.
You can easily translate gestinux into your mother language, and existing translations can definitely be improved.
The documentation, this Wiki, is made with MediaWiki and you can improve it. Read this page for more information.
For any question or remark, it is necessary to use only the forum and not the wiki.
Lazarus versions and sources
Gestinux 1.5 was eventually developed using Lazarus 2.0.10 and FreePascal 3.2.0.
Obtaining Gestinux sources
Gestinux source code is managed using SVN.
You must also have a SourceForge account and will need to enter your SourceForge password, or set up a SSL secured connection to SourceForge.
The svn command line is :
svn checkout --username=your_sourceforge_account svn+ssh://email@example.com/p/gestinux/code <your_local_source_directory>
Read this documentation to avoid entering your password every time.
- You should improve or create new sources and/or new functionalities in the trunk branch only, after having obtained a developer profile in the sourceforge project (ask in the development forum).
- In the last stable branch, only fix important and well identified bugs.
- Do not change anything in older branches which are available for history only.
You should lock the files before changing anything. For this and to commit, ask in the forum to be granted a "developer" privilege for Gestinux SourceForge project.
Packages which are required
Releases 1.x or trunk should compile with the following packages.
You can use more recent versions of the packages, but at your own risk ! Let us know if using a newer version of any of these packages works sucessfully.
- Zeos DBO 22.214.171.124
- Download sources and unzip in any folder.
- Open packages/lazarus/zcomponent.lpk
- Install (click Use, Install)
- It is not required to rebuild the EDI before all packages are installed
- Power PDF 0.9.15
- Download the package and unzip to any directory.
- Open pack_powerpdf.lpk
- LazReport 0.9.9 and LazReportPDFExport 0.9
- Click Menu Packages > Install/Uninstall packages
- Select these packages (lazreport and lazreportpdfexport) in the right pane, and move them to the left one.
- Gestinux_util 1.5 or 1.6 : package containing the components Gestinux uses, located in the util subdirectory of 1.5 or trunk branch.
- Open gestinux_util.lpk
- Click the button Save and rebuild EDI
Gestinux development Rules
- Use the right Lazarus version (see above)
- Only use English for identifiers and comments.
- Use the Code Formatter (CTRL+D) to indent modified sources, with default options.
- Read the gestinux_util documentation, and do not use a Txxxx component when there is a TGxxxx component in this package
What to do
Everyone can help ! If you are a beginner, there are some simple things you can do, and this would save time. From gurus, we do need better components.
Before starting anything, you are advised to discuss your proposal a bit in the development forum.
Packaging and OS specific informations
You can build a Debian package using scripts located in trunk/install/debian
Source are exported from the repository and recompiled before building the package, to ensure everything is in the repository. The SVN revision will be included automatically in the binary to be visible in the "About" form.
If you want to build and install a package run (e.g with trunk and Lazarus 64 bits). Replace <svn local repository> and <your sourceforge account> by your specific values.
<svn local repository>/gestinux/1.4/install/debian/build_pkg.sh SYSTEM="Debian" TARGET="x86_64" SVNUSER="<your sourceforge user>" BRANCH="trunk"
This should build a lintian valid Debian package, reading some translations for man and desktop in available translation files.
You are welcome if you can make the same for other Linux distributions !
You can build an installer for Windows 32 bits with InnoSetup 5 and the command file trunk/install/windows/build_i386_win32.bat. Windows PowerShell is used to extract and include the SVN revision in the binary.
It can be installed and works on Windows 64 bits. It is also possible to use build_x86_win64.bat, with Lazarus 64 bits, to make a 64 bits installer. Since this is not very useful and not used currently, check if the script is up to date against the 32 bits one.
We include MySql 5.0 client drivers, installed only on the target system if no more recent MySql driver is present .
Currently gestinux.app can be built for Intel 32 bits with the script trunk/install/osx/build_osx_i386_32.sh.The SVN revision must be included manually. There is a gestinux.pmdoc to make manually a gestinux.pkg which can be installed and works on 32 or 64 bits Macs.
Since I have only an old Macintosh with OS/X 10.6, I can't use up-to-date tools to build installers and add certificates.
You are welcome if you can help in this area.
MySql 5.7, MariaDb 10.3, and PostgreSQL 9 are supported.
- MySql because administration is quite simple.
- PostgreSql because it is completely free software.
- MariaDb for both reasons. It is the recommended DBMS to use.
In the future, we may try other DBMS, but that would require a bigger development team.
In the main sources, avoid SQL statements specific to some DBMS. When there is no alternative, compatibility procedures should be made. They are all centralized in one unit (util/gconnection.pas).
Table and fields definitions and properties
In Gestinux_util there is a TGTable component used to store all the metadata of tables used in Gestinux. With this component, there is no need to store table definitions elsewhere, and no SQL script is required to initialize or upgrade the database.