forums.silverfrost.com

[stfark1]

I have noticed that when I have a project open and make a change to one of the Fortran routines, if I then do a build, the change does not seem to be there. However, when I do a re build, the change seems to be there. Questions is:

Significance of:
-build
-rebuild
-rebuild dependencies
-clean

What does each do and when to use.

[PaulLaidler]

On the Project menu you should normally have "Enable Dependency Checking" switched on.

Then when you make a change to your code and select Build, the change is automatically saved and included in the build process.

When you select Rebuild, then all the project files are recompiled regardless of any changes.

However, you can change this behaviour in the project settings. For example, you can elect to leave a particular file in the list of project files but exclude it from the build process.

[DanRRight]

All such tricks will be lost if not included into added menu "Tricks everyone has to know"

[KL]

Just two little comments: At the moment, I am working on a project consisting of approximately 450 subroutines and functions. Nearly all of them use a global data module. I would expect that when the global data module is modified, all procedures using it are automatically recompiled. Neither under Plato (�Enable Dependence Checking� is checked) nor for the Visual Studio 2015 plugin this is the case. Only a few procedures are recompiled. Running the produced executable leads to a disaster. A complete rebuild is the solution.

With Plato there is another problem: it does not allow to add all 450 procedures. One can add only around 100. After that, dependency checking starts automatically, which takes rather long. My impression is that during the dependency checking is running, further programs should best not be added. Are there built-in limitations?

KL

[KL]

Just two little comments: At the moment, I am working on a project consisting of approximately 450 subroutines and functions. Nearly all of them use a global data module. I would expect that when the global data module is modified, all procedures using it are automatically recompiled. Neither under Plato (�Enable Dependence Checking� is checked) nor for the Visual Studio 2015 plugin this is the case. Only a few procedures are recompiled. Running the produced executable leads to a disaster. A complete rebuild is the solution.

With Plato there is another problem: it does not allow to add all 450 procedures. One can add only around 100. After that, dependency checking starts automatically, which takes rather long. My impression is that during the dependency checking is running, further programs should best not be added. Are there built-in limitations?

KL

[PaulLaidler]

KL

As far as Plato is concerned, when there is a change to a module then I would expect that all files in the project that USE that module would be automatically recompiled (when dependency checking is switched on).

Dependency checking can be switched on or off by the user. It will always be applied when switched on. There is no automatic on or off.

In the past there was a problem with the dependency checking for projects with a large number of files but this was fixed and should be OK in the latest version of Plato.

It may be possible to fool Plato by having a module structure in the project that is recursive (e.g. module A depends on module B whilst module B depends on module A, it is usually more complex than that) but even then Plato should time out with an error report.

I have seen user projects where the module structure is recursive and where a clean rebuild is impossible and can only be achieved by bootstrapping in some way.

[KL]

Thank you very much, Paul for your quick reply.

In the program there are only a few modules and there is no recursive module structure. �Enable Dependency checking� is checked, the Plato version is 4.83.

To further investigate the case, I copied today the program into three different directories, from which I created a) a Visual Studio project (VS), b) a Plato project and c) a Code::Blocks project. I ensured again that all files in the three directories are identical. I compiled all projects with the Debug option and ran an identical case. The results of VS and Plato are identical (in the output some cut-offs may have happened), the results of Code::Block employing the GNU Fortran compiler are the same within the numerical accuracy.

After this test, I added a blank line to the global data module �Global_Data� in all 3 directories. The new build produced the following results:

VS: compilation of �Global_Data� and just one subroutine with the corresponding Use statement.
Plato: compilation of �Global_Data� only; For Plato, I have rebuilt dependencies and changed �Global_Data� again. The result was the same.
Code::Blocks: compilation of more than 400 procedures.

Since I have seen this behavior before, my workaround is rather simple: if a module is modified, I always do a rebuild, which I also do from time to time.

Klaus

[KL]

PS. For Visual Studio 2015 I may have found the solution:
Tools --> Options --> Projects and Solutions --> Build and Run: Uncheck �Only build startup projects and dependencies on Run�

[KL]

PS. For Visual Studio 2015 I may have found the solution:
Tools --> Options --> Projects and Solutions --> Build and Run: Uncheck �Only build startup projects and dependencies on Run�

[PaulLaidler]

KL

If you are able to zip up and send me your project then I will check it out.

[KL]

Dear Paul,

Thank you very much for your offer. Unfortunately, I am not allowed to release the code.

Today, I made several tests to recheck some of my experience with Plato:

- When too many existing files are added, Plato may crash. When reopening the project in this case, all added files were moved to �Include Files�. Pressing �Build� leads to the error message �Error: No source files have been added to this project�. I have reproduced this unbelievable error three times.

- One would expect that for a new project the modules are compiled first, which is not the case. The build process may take up to three steps. Of course, the modules could be compiled manually first in their right sequence.

- Plato offers 9 compiler options (Checkmate, Debug and Release each for Win32, x64 and .NET) and the user sees immediately the advantage: It is possible to compile and run Fortran programs under Win32 and x64 as well as produce a .NET dll for linking with other .NET projects, for instance with a .NET GUI, which is a very attractive combination. The compiled programs are stored in separate directories (Checkmate etc.). In the project directory information on modules is stored: *.mod for win32, *.mod64 for x64. I cannot see something similar for .NET and it is rather tricky to switch from Win32 to .NET (again through a three-step build process or the deletion of the *.mod files).

My very personal view is that on one hand side a huge development of Plato took place in the last years (Win64, .NET), but some further consolidation might be needed.

I would like to take this opportunity to report two more specific problems:

- It seems that there is an inaccuracy in the .NET compiler. Our program analyses a time dependent problem in thousands of time steps. All big arrays are allocated only once at time 0, some subroutines use array sections as arguments. Since .NET languages do not have something equivalent, an array section is probably copied internally to a new array before being passed to a subroutine. On return this array must be copied back into �its� section and the temporary array should be deallocated. (May be that I am completely wrong with that hypothesis). The program works and the starts to run as usual. However, after a couple of time steps the memory is exceeded (�Salford.Fortran.RuntimeException: 199; Run out of heap space�). Since this program runs the same data case on a 20 years old laptop with unbelievably low performance data I presume that the temporary arrays to which the array sections (approximately 200*200*4) have been copied many times have never been deallocated.

- In .NET Checkmate there is still an �old� error, which has already been corrected for Win32/Checkmate:

[PaulLaidler]

Klaus

Thanks for your detailed feedback. Unfortunately we can only offer to fix issues and failures that we are able to reproduce. So, apart from one part of your report (with code for a .NET failure), we would need further information in the form of code that illustrates the problems that you have encountered.

[KL]

Paul, I understand.

Please find below two little test programs for those problems, which I can condense and send out:

Test98 gives for .NET Checkmate "error 431: Active Do-loop index altered". It is bad programming anyhow but it should not lead to an error

[KL]

[KL]

Has anybody looked at Test98 and 99? I am especially interested in Test99 since it seems to be obvious that for the array section to be passed an internal array was initiated but not closed.

Klaus