fpc trunk & mseide issue

[fochen79]

Hi
i just noticed that when you use fpc trunk the mseide keep compiling msegui units every time you hit make
note that the siwtch -B is unchecked , with fpc 3.2.2 all works ok

can you check please

[fredvs]

I will check asap but, imho, it is a problem of fpc, not msegui. (but of course I may be wrong),

[fredvs]

What Os are you using?

[fochen79]

i am using windows 7 32bits and windows 10 64bits

[fredvs]

Did you try with Lazarus, is it ok there?

[fredvs]

Re-hello. I dont have a Windows machine to test at the moment.
But I cannot figure how mseide could have implication on this.
The only thing that is sure is that fpc has a long time bug, when you dont use -B, fpc ignore the
"ifdef" or "if defined" declaration when something was changed, maybe they have try to fix it in last commit (but now -B is always added). Maybe.

[fochen79]

Hi Fred , i just tested lazarus & fpc trunk , it works ok
about the -B switch , i removed it from the project option , but the compilation acts like its on
will try with other msegui versions , maybe will catching something

[fredvs]

You are right: here on Linux 64 bit using fpc trunk and disabling -B also make fpc a full compilation of all units, even not changed.
And with fpc 3.2.2. or fpc 3.2.4. it is ok.
Hum, long white nights to investigate in perspective...

;-(

[fredvs]

Some news from the front.

I did try to use the fpc trunk compiler but via a terminal.
So I did this to compile mseide:

$ /home/fred/fpcupdeluxe/fpc/bin/x86_64-linux/fpc -FUapps/ide/units -Fulib/common/* -Fulib/common/kernel/linux apps/ide/mseide.pas

The good news: mseide compiles and run ok using last fpc trunk.

But, but, but, recompiling mseide using same command line (so without -B) makes fpc-trunk to recompile all the code, even not changed.

I then retry using fpc 3.2.2 and 3.2.4 and there, after first complete compilation, without -B, only few units are re-compiled, as wanted.

So, imho, it is a problem of fpc-trunk, maybe Lazarus has a workaround for this, but it is clearly a fpc bug that did not exist in 3.2.2 and 3.2.4.

PS: Sorry but I dont have the courage to create a issue in fpc-git, if you are brave and courageous, please do it.

Anyway, many thanks to discover and note it.

[fredvs]

Aaargh, no so simple.

When compiling a big app like mseide, using fpc trunk, it compiles every time all the units, even without -B.

But compiling this simple empty app with fpc trunk:

program test1;
uses
BGRABitmapTypes;
begin
end.

with this:

$ cd /dir/of/bgrabitmap
$ fpc test1.pas

compiles all the units at first time, but without -B he only does a link of the already compiled units.
Mamamia, once again a head breaker...

EDIT: There is a topic in Lazarus forum about this: https://forum.lazarus.freepascal.org/index.php/topic,69929.msg544509.html#msg544509

Conclusion: I fear that mseide cannot solve anything for that.

[fochen79]

Hello fred , this is really strange , but i don't think its caused by fpc ( maybe i am wrong )
for example i create a simple console app , then i've added simple 4 units , and the compilation works as expected , only the modified files is recomplied , so the problem is only with gui project
i will investigate a little more

[fredvs]

Yes, I noted this also, read my previous message and the post I sent in Lazarus forum.

[fredvs]

In mseide code, all the lines in the messages form are the result of fpc output when compiling.
I checked again, there are no filters for gui or big or little code, it is only the result of a TProcess (here fpc(.exe) + parameters) , no more no less.
Or I'm missing something and should have a consultation with an optician.

[fredvs]

Answer from PascalDragon, developer of core fpc in Lazarus forum: https://forum.lazarus.freepascal.org/index.php/topic,69929.msg544590.html#msg544590

Quote from: Fred vS on Today at 02:34:42 am
Same kind of problem here with last fpc main/trunk.
Compiling big apps without the -B parameter makes fpc recompile all the units at first compilation and it is ok.
But recompiling without any change and without -B, all the units are once again recompiled.

We are aware of this. The problem is that we haven't yet managed to find a small example that allows to easily reproduce and thus debug this (e.g. compiling the compiler triggers this issue as well). My suspicion is that it's depending on the dependencies between the units, so it should essentially be reproducible with empty units that only contain uses-clauses. This is one of the reasons why I don't consider main as even remotely release ready, cause this consistent recompilation is a no-go.

so the problem is only with gui project

They have the same problem recompiling fpc himself, that is not a gui app.

[fochen79]

thanks for the link
so its fpc issue , i wonder how lazarus guys manage to figure out how to get ride of this problem , because as i said lazarus & fpc trunk works fine
but i think no worries since ( Sven as on of the fpc core team ) know this already , so sooner or later they will (hope) fix it

[fredvs]

, i wonder how lazarus guys manage to figure out how to get ride of this problem , because as i said lazarus & fpc trunk works fine

Hum, are you sure about this?
I did try to compile mseide using Lazarus (Project/New from file) and here, even without -B or choosing in menu fast compil, all the units are re-compiled.

[fochen79]

no , i mean lazarus LCL source , , when you create an LCL gui application , the compilation affect only the project main file ,

[fredvs]

Ha, ok, so maybe some light for Sven (but I dont think Lazarus has a workaround for this, only the units used by the project are not affected by the bug but, of course, I may be wrong).

[fredvs]

Ok, ok, ok, I will continue the combat to find what is wrong in fpc.

I did try this: create a new msegui simple application, using the default template.
So only a widows, nothing more.
Here, without -B, after first compilation, it is ok, only linking is done if nothing changed.

So the challenge is to find what new unit added makes fpc re-build all without -B.
And see what is different with that unit.

My first guess: something about the inc added in a unit.

[fredvs]

Sorry if I will monopolize the issue but I prefer to give here the result step by step of the combat to remember what I did.

Next step, just add a TButton on the form, nothing more.

Compile the demo without -B, fpc "Error: Compilation raised exception internally"
OK, experience knows why, so added -B and recompile.
Compilation is ok and all the units are compiled because of -B.

Now test recompiling without changing anything, but removing -B.

Booom, now all the units are recompiled!

Now, delete the TButton from the main form and recompile.
"Error: Compilation raised exception internally"
OK, recompile the form without the button with -B.
And retry to compile without -B.

Re-boom, the form without button re-compile all the units.

OK, removed the unit msesimplewidgets that was added in main unit when the button was added in the form (and not removed when button was deleted from form).

Yep, now re-compilation is ok without -B, all the units are not recompiled.

So here the problem is adding msesimplewidgets unit force to rebuild all everytime.

Next step, what has that msesimplewidgets,pas unit to force re-compilation.

[fredvs]

Other problem. With fpc trunk, after close + reload the simple project, here re-trying to recompile the application without -B, the compilation block when trying to compile mseguiintf.pas, all is blocked, have to stop the compilation (but it still use memory and cpu, even if compilation was aborted).

Compiling /home/fred/mseide-msegui_sdl/lib/common/kernel/linux/mseguiintf.pas

This does not append with fpc 3.2.2 /3.2.4, compilation is ok only if add -B with fpc trunk (or if it add by himself).

Sorry but I give up, too many things are not ok with fpc trunk.

[fochen79]

yes me too i've encountered all those problems you've mentioned
i think fpc trunk is still buggy , so its better to wait for the upcoming releases .
for now everything works fine with 3.2

[fredvs]

Yes, fpc trunk is not yet for production. But I did not find problems on execution of programs when -B is used.

[fredvs]

Note that in the .prj of the demos in mseide-msegui source all the modes of compilation (M, B, 1, 2, 3, 4) have, since long ago, the -B parameter.
This because all versions of fpc have problems without using -B, sometimes (and I did not find why/when) the declaration in {$ifdef something}dosomething{$endif} are omitted!
And this for all kind of code, LCL, fpGUI, msegui or console.
The -B was added for all mode in demos because people created issues for this, examples: #37 , #36 , ...