Development Team Blog

During the development of Visual DataFlex 12.0 we modified the compiler to track any changes to source code that belong to a precompiled package. For example, let's say you have a precompiled package (MyPrecompile.pkg) and one of the files used by MyPrecompile.pkg was edited since it was last precompiled. Now, when you go to compile a project that uses this precompile, the Compiler would detect the change and raise an error that the precompile is out of date.

This was a good change because previously the compiler would just use the out of date precompile with no warning. The results could be confusing as the changes you expected to see would simply not be there. Even worse is if you were using the debugger and stepping through code, the source code you are stepping through might not match the instructions being executed, producing "out of sync" behavior in the debugger.

In Visual DataFlex 12 the Compiler raises an error telling you which package needs to be recompiled. You then go find that package, precompile it, and you are ready again to compile your project.

The Missing Step

What we realized after the release of Visual DataFlex 12 is that this change wasn't as helpful as it could be. Since you cannot compile a project with an out of date precompile, and the Compiler knows the name of the file that needs precompiling, why doesn't the Compiler just go ahead and precompile that file automatically?

Complexity

As usual, the answer was not exactly straight forward. Source code belonging to a project can be located in three distinct regions: It can be local to the current workspace; it can be local to a library that is used in the current workspace; or it can be a global package (one of the packages installed with Visual DataFlex).

A precompiled file can exist in any of these areas. The problem with library, and global precompiles is that they are shared by other workspaces. When you precompile a file, the compiler will apply the makepath associated with the current workspace. Each workspace has a different makepath. Precompiling a library package could cause symbols defined in the current workspace's makepath to be compiled into the library package. This could cause a problem when the library precompile is used by a different workspace that has a different makepath and may have a different definition for some symbols.

For this reason it is simpler and probably safer to not use precompiled files in libraries. We recommend that you create a local precompile in each workspace. This can include use statements that precompile the global packages as well as all of your library packages. The problem is that this can be a pain because when you make a change in one of your libraries, you will need to manually recompile each workspace's precompiled package.

Automation

For Visual DataFlex 2008 we have simplified this process. If you have a local workspace precompiled package and one of its files are out of date, then when you compile a project, the Compiler reports the problem to the Studio. The Studio then remembers the project that was being compiled, starts precompiling the package, and if that succeeds it returns to compiling the original project.

Actually it is better than that. If the precompile also uses another local precompiled package that is out of date, then the Studio pushes the first precompile onto the stack, precompiles the second package, then traverses back up the stack until the whole chain is compiled properly. This will work for any number of nested precompiled packages, so long as they are local to the current workspace.

If there is an out of date precompile that belongs to a library, then the compiler stops and tells you you need to precompile that package manually. You would do that by loading the library workspace (in another Studio instance), and precompiling the file from the library workspace's context. This ensures that the library precompile is created consistently for all workspaces that would use it.

Setting Up For Automatic Precompilation

How does the Compiler know when a package is intended to be a precompiled package? Firstly the package should be the first compiled line of code in your project. Next, the compiler looks for evidence that the package has been precompiled before.

This means that in order to set up a project to use automatic precompilation, you will need to manually precompile your package one time. This is quite easy to do. You simply open the package in the Editor and choose "Precompile Package" from the Project menu.

We have also added a context menu option in Code Explorer so that you don't even have to open the precompile package. Make your project.src the current file that you are editing, then simply select the first Use statement in the Code Explorer treeview and choose "Precompile Package" from the context menu.

Once that is done, all your precompiled packages will be kept up to date automatically. All you have to do is compile your project and the Studio will take care of the rest.

The Compiler output in the Studio's Output Panel shows the history of each file that needed to be compiled.