Author Topic: Timing (?) problem in CodeBlocks with gfortran modules  (Read 7031 times)

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Timing (?) problem in CodeBlocks with gfortran modules
« on: June 04, 2010, 12:01:07 pm »
I have a problem in generating fortran 90 project using modules. It looks like a timing problem between a file creation and it's effective creation on the disk. This problem happens in Windows (XP3 in my case) not in Linux.
I use MinGW tdm last distribution (as you have in C::B 10.05) except than I use gfortran 4.4.0 not 4.4.1 because on some projects I have some problems with this last version.

See this test case in Test_f90_modules.7z.

I have a main program in aa.f. This program uses two modules. Module cc which is in mod_cc.f and module bb which is in mod_bb.f.
Module bb itself uses module cc. So the first thing to do is to set correctly build priorities to force the right order of compilation.
So I set priority 0 to mod_cc.f, priority 25 to mod_bb.f and default priority 50 to aa.f. (Right clic on each .f file in Management window, Properties..., Build, and setting the priority weight to the correct value).
Like that, when mod_cc.f is compiled, it creates a mod_cc.o in /obj and cc.mod directly the main folder.
Same thing for mod_bb.f. But, cc.mod must exist at compile time.
Then when aa.f is compiled, cc.mod and bb.mod must exist at compile time.
On Linux, as I said, no problem. Build process is correct.
On Windows, it's different.
If I build the project (click on main task bar build button), mod_cc.f is compiled but when mod_bb.f is compiled I obtain an error message sayind that cc.mod is not here. But If I look in my folder, I can see it : it has been created. If I again build the project (here cc.mod already exists), mod_bb.f is correctly compiled and bb.mod created, but when compiling aa.f, I obtain an error message saying that bb.mod is not here. Nevertheless, I build again and that time all is OK. So, for this project, I need to click 3 times on the main Build button (or Ctrl+F9).
Now, if I try to build manually the project, starting from a clean folder, no .exe, no .o and no .mod, by :
1) right click on mod_cc.f and click on Build file
2) right click on mod_bb.f and click on build file
3) Click on the main build button.
Like this, everything is OK.

Builds logs in Builds_logs.7z

So, if doing manually the total build works, but the global automatic chaining build does not work. It looks like there is a timing problem. I think, but I am not totally sure of this, that there is a problem with the cache system on Windows. When chaining automatically, mod_cc.f is compiled creating effectively mod_cc.o and cc.mod, but cc.mod may be is still in the cache and not still physically on the disk when mod_bb.f is compiled, so generating the error. Next time, it's OK, because cc.mod is already there, but in fact, it's the previous compiled version which is used. It could be a problem if I modify something in the module between the 2 builds.

An other problem, related with this, is that when you Clean (or Rebuild) the project, the executable and .o files are first deleted, but it's not true for .mod files. You have to delete them manually. I tried to add an rm *.mod in pre-build step, but it is not a solution because .mod files are deleted even if nothing has changed in the modules.

And finally, I think I have quite a similar problem when building CodeBlocks itself on Windows from svn files (never happen on Linux). I have often, but not systematically, an error when I build the workspace (and sometimes rebuild) because some files as sdk.h or sdk_precomp.h (and sometimes others) are declared as missing. But I can see them in my folders. I just need to build again the workspace, and that time, the previous declared missing file is found. May be a similar problem with cache disk on Windows.
So if effectively it's the same problem it's more a CodeBlocks problem on Windows than a gfortran one.

gd_on



[attachment deleted by admin]
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #1 on: June 04, 2010, 01:33:19 pm »
Did you check "Settings -> Compiler and debugger... -> Global compiler settings -> Other settings -> Compikler-independent settings -> Number of processes for parallel build".
I sometimes get errors on linux with your project , if it is set to more than one, but most time it works.

On Vista it works, if I set it to one, otherwise it fails.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #2 on: June 04, 2010, 02:50:01 pm »
I recall I had similar issues, too when using parallel builds with gfortran.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #3 on: June 04, 2010, 03:23:17 pm »
Yes, there was 2 parallel process on my Windows machine (It's a dual core, so why not !). If I set to only one, it works.
Nevertheless on my linux machine, this parameter is set to 4 (It's a 4-quad core processors machine and I think I can go up to 16 parallel process, but .... my colleagues are not happy with that). I have no problems on this linux machine (until now  :( ).

Concerning the last part of my post when building CodeBlocks itself from SVN on Windows, it happens on a single core machine with this parameter set to 1. But may be it's not exactly the same problem. gfortran is not guilty in that case !

gd_on
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #4 on: June 04, 2010, 03:28:20 pm »
I have such issues on windows when using ccache, egally if I use 1 process or multiple ( I have 3 normally on a core2duo).

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #5 on: June 04, 2010, 03:37:03 pm »
And what about .mod files not deleted when Cleaning or Rebuild a project ?
Is there a workaround ?

gd_on
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #6 on: June 04, 2010, 05:43:45 pm »
Is there a workaround ?
What about a simply post-build step (using macros)?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #7 on: June 04, 2010, 06:38:41 pm »
Do you mean : deleting .mod files at the end of the gfortran build process ?
Normally, they are only useful at compile time if I understand well. So, if you don't modify your gfortran source project, they are not used any more and if you modify it, they need to be rebuilt. Why not... But I have to add this manually. The best place to do that should be in global compiler settings, but this possibility is only present on each project build options. So for complex multi project it needs a lot of modifications. It could be nice if CodeBlocks could do that automatically, and may be in the cleaning phase.

gd_on

PS : Finally, not a solution. If you delete .mod files at the end of a gfortran build, you can need them for  a future compilation. For example, in my test case, .mod files are build from mod_bb.f and mod_cc.f. If I modify the main code aa.f, I need bb.mod and cc.mod. So the only solution is that the cleaning process should delete them. I don't know if it's possible to add a pre/post build step there.
« Last Edit: June 05, 2010, 11:21:11 am by gd_on »
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #8 on: June 07, 2010, 10:04:01 pm »
I don't know if it's possible to add a pre/post build step there.
Notice that you can also setup a "commands only" target for such purposes. It does what it's name applies: Compile nothing, just run commands - like delete files in your case.

In addition you can add it to a virtual target or just run this very target if needed. This should solve your problem - it's very flexible to use...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline gd_on

  • Lives here!
  • ****
  • Posts: 797
Re: Timing (?) problem in CodeBlocks with gfortran modules
« Reply #9 on: June 08, 2010, 09:05:12 am »
I'll have a look to this last solution, but only in a few days (other urgent things to do before  :()

gd_on
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).