GST External Projects

When transitioning into a development environment based on Genero Studio, one of the decisions you will have to make is how you structure your project (sometimes known as the 4pw) file or files.

I think of the project file as similar to a makefile.  It holds the information about the various Genero source files that make up a Genero application.  It has the information that is needed to compile a Genero application, that is you need these .4gl, these .per or .4fd files etc.  From the projects view, a developer can quickly maintain and edit any of these source files.  The developer can also maintain the build, package, and execution rules for the Genero applications in the project file.

Genero solutions are typically made up of a number of Genero applications.  Each Genero application will have its own unique sources as well as common sources and libraries that are shared by a number of all applications.  Where there are many Genero applications, these may be broken down into groups of Genero applications.  There isn’t a Four Js term for this but I have seen the terms module, sub-system, package, group all used.  I will use the term module.  ERP solutions might have a sales module, a purchasing module, a debtors module, a creditors module, a GL module, an assets module etc , each module containing a number of Genero applications.  For example, a large ERP system might have 20 modules, each containing on average 20 applications, so 400 Genero applications in total in one solution.

As I mentioned at the top, one of the decisions you will make is how to structure your .4pw project file.

If you place all your Genero applications into a single project file, you are then going to face some potential issues.

If two or more developers edit and make changes to a .4pw at the same time, how will any conflicts be handled and merged.  Deep down the .4pw is an xml file (open it in a text editor and see for yourself).  The version control system you use only knows it as an xml file and so any conflicts / merges may have to be manually handled by editing the raw xml.  This is a characteristic of any GUI source file such as 4fd, 4ba, .4db and some of the other BAM files.  Ideally most of these are all small enough so that only one developer is editing them at a time and merge conflicts are rare.  If your .4pw as in my example scenario has 400 applications, it is conceivable that multiple developers may have this file open for changes at the same time and you may then encounter merge conflicts.

Another issue that you will face is that Genero Studio does perform certain actions on the whole project or reads the whole project to do certain actions.  Take for example when you are using version control, in the projects view is a small icon that indicates the status of the file with respect to version control.  A white tick on a green background for upto date, a white exclamation mark on a red background for not upto date.  When opening Studio, how many of those status checks on your version control are going to take place?. Similarly  if you select Compute Dependencies from the Projects menu how many files are the dependencies going to be computed across?

We don’t impose a limit of number of files in a .4pw but you may get to a point where instead of having a monolithic project file, you think can I have lots of smaller ones instead?  The same principal applies to makefiles, did you have one monolithic makefile or did you use the include syntax to reference a common makefile.  The Makefiles in FGLDIR/demo/*/Makefile do this with the entry “include ../Makeincl”

You can structure your Genero project files in a similar manner using External projects.  Using this technique every single Genero application might have its own unique .4pw file.  For your daily builds, you can then have a 4pw, named say all.4pw and you import the many .4pw as External projects into this project.  Doing a daily rebuild is then as simple as rebuilding all.4pw.

Using this technique you can have multiple tiers.  I mentioned earlier that large systems might group their Genero applications into modules based on functionality.  So you might have a sales.4pw, a purchases.4pw, debtors.4pw, creditors.4pw and group your applications into these modules.  These could contain the Genero applications or you might in turn reference external projects for each individual Genero application.

Using these external projects you can view and rebuild the external project, but it is read-only.  To make changes to an external project you have to explicitly open it.