FPC compatibility in general

[circular17]

Having a folder with copies of FPC packages that are tweaked with mclasses unit leads to incompatibilities when using packages that are not included in the folder.

Two solutions to avoid this problem are :

• prefixing unit names with mse
• adding bridge classes to plug together Classes and mclasses

As Fred suggests we can compare Classes and mclasses to see what are the difference and see what really needs to be tweaked.

If no tweaking is needing it would simplify to remove the files from the compatibility folder.

[fredvs]

prefixing unit names with mse

Imho, only the ones where deep change was made in code. If only was added in uses section mclasses, imho, your bridge is perfect and the files may be deleted.

[fredvs]

I am a little afraid to break compatibility for msegui himself. If you dont link to the original msegui tweaked fp* it could have problems if not only mclasses was added.

What I propose and it works perfectly, is to rename all the tweaked fp into msefp and in msegui code replace all call to fp by msefp.

Tested and works like charm.

So for himself, msegui will use msefp, and you, if you want, you may use the official fp + your bridge.

[circular17]

I would say that for now, I prefer not having to rename units because that would add a lot of $IFDEF in BGRABitmap.

I understand you don't want MSEgui to be broken when using original FPC files. Though in the long run, avoiding those duplicate files would reduce maintenance and updates.

When I have the motivation, I will have a look and try to understand what is the point of mclasses. Maybe my idea of removing the compatibility folder is impossible, but I would prefer to make sure of it.

[rchastain]

Having a folder with copies of FPC packages that are tweaked with mclasses unit leads to incompatibilities when using packages that are not included in the folder.

For easier discussion, please could you provide a test project which shows that problem?

[rchastain]

When I have the motivation, I will have a look and try to understand what is the point of mclasses.

Yes, that is what we have to do. I will take a look today.

[circular17]

For easier discussion, please could you provide a test project which shows that problem?

Here is a sample program:

program testzipper;
{$mode objfpc}
uses
 {$ifdef unix}cthreads,{$endif}
 zipper in 'C:\lazarus\fpc\3.0.4\source\packages\paszlib\src\zipper.pp';

var 
  unzipper: TUnZipper;

begin
  unzipper := TUnZipper.Create;
  unzipper.FileName := 'somefile.zip';
  unzipper.UnZipAllFiles;
  unzipper.free;  
end.

which does not compile: zipper.pp(835,60) Error: Incompatible type for arg no. 2: Got "CLASSES.TStream", expected "MCLASSES.tstream"

[rchastain]

Here is a sample program:

OK, thank you.

FYI, I found an interesting example in MSEuniverse: https://github.com/mse-org/mseuniverse/tree/master/tools/mse-installer

[circular17]

Ah yes I remember you mentioned it. I'm going to look at it now.

Get an error opening the project:

And an error when compiling:

Compiling mse-installer.pas
Fatal: Can't find unit system used by mseinstaller

[rchastain]

@circular17 Yes, I had the problem. Let me some time, I will provide a corrected version. If you want to do correction by yourself, you have (if I remember well) 1° to remove everywhere in mfm ow_autoscale and ow_fontglyphheight values 2° to edit macros in project options.

[circular17]

Ok I will try that.

Well I don't know what to do to fix the System-not-found error.

[rchastain]

Well I don't know what to do to fix the System-not-found error.

In "project options, make, directories," replace $TARGET with $TARGETOSDIR.

[rchastain]

There are still other problems (Identifier not found "tmacrolist", etc). I solved them yesterday like a butcher. I am trying to do it in a better way now.

[rchastain]

This one is not so simple to fix:

globmodul.pas(155,60) Error: Wrong number of parameters specified for call to "add"

So temporarily, I comment all these lines:

fmacro.add(['HOMEDIR'],[removeendpath(sys_getapphomedir)]);

[circular17]

Changing $TARGETOSDIR didn't work for me.

I suggest that if you find a way to fix it that you propose your changes to the repository.

[rchastain]

Changing $TARGETOSDIR didn't work for me.

Did you fix the macros?

I suggest that if you find a way to fix it that you propose your changes to the repository.

OK, I will do it.

[rchastain]

For me, once I have made all that modifications, I fall on the zipper problem:

PPU Loading /usr/lib64/fpc/3.0.4/units/x86_64-linux/paszlib/zipper.ppu
PPU Source: zipper.pp not available
Recompiling zipper, checksum changed for zstream
main.pas(109,11) Fatal: Can't find unit zipper used by main

[rchastain]

To fix the macros problem, I simply selected Active group 4, which doesn't exist. But maybe it won't work for you.

[circular17]

For me, once I have made all that modifications, I fall on the zipper problem:

PPU Loading /usr/lib64/fpc/3.0.4/units/x86_64-linux/paszlib/zipper.ppu
PPU Source: zipper.pp not available
Recompiling zipper, checksum changed for zstream
main.pas(109,11) Fatal: Can't find unit zipper used by main

Did you remove the in '...' after the zipper in uses clause?

[rchastain]

Did you remove the in '...' after the zipper in uses clause?

I wasn't speaking of the short example that you provided, but of main.pas (mse-installer.prj) and setup.pas (setup.prj).

[rchastain]

As I am not very good at git, and as the project isn't really fixed, I prefer not to touch to the git repository for now. So here is the project retouched. It doesn't compile, because the zipper problem is not solved. I let you find and experiment your own solution.

Edited. File removed. See new version below.

[circular17]

I wasn't speaking of the short example that you provided, but of main.pas (mse-installer.prj) and setup.pas (setup.prj). There's no in there.

Oh I see. Well you need to have zipper.pp in msegui\lib\common\fpccompatibility. With the mclasses tweak.

[circular17]

Ok I compiled it. There was some missing parameter to tbitmap.loadfromfile (just an empty array). Also I retreive the RES files from the original folder.

I get the following error at runtime:

I take a break.

[rchastain]

Oh I see. Well you need to have zipper.pp in msegui\lib\common\fpccompatibility. With the mclasses tweak.

Yes, that's what I did yesterday. But if I well understand the first message of the discussion, there are problems with that solution, isn't it?

[rchastain]

There was some missing parameter to tbitmap.loadfromfile (just an empty array).

Thanks for the tip.

I get the following error at runtime:

Yes, there were invalid properties. Even after I removed them, there still was an error, I don't know why. My trick in that case is to change randomly a value in the object inspector (in this case I reset the options to default options) and save the file.

Here is the valid mfm.

main.mfm.zip

[rchastain]

A first view of differences between classes and mclasses:

{ classesh.inc } TPersistent = class(TObject,IFPObserved)
{ mclasses.pas } tpersistent = class(TObject{,IFPObserved})
{ classesh.inc } FObservers : TFPList;
{ mclasses.pas } //    FObservers : TFPList;
{ classesh.inc } TComponent = class(TPersistent,IUnknown,IInterfaceComponentReference)
{ mclasses.pas } tcomponent = class(tpersistent{,IUnknown,IInterfaceComponentReference})
{ classesh.inc } function GetComObject: IUnknown;
{ mclasses.pas } //    function GetComObject: IUnknown;

[fredvs]

Changing$TARGETOSDIR didn't work for me.

Please use the brackets: ${TARGETOSDIR}

I fall on the zipper problem:

@rchastain did you try with last commit of mseide-msegui?

[fredvs]

Sorry to come a few late in the game but what demo/test are you trying to compil and that gives all the errors?

[rchastain]

@rchastain did you try with last commit of mseide-msegui?

No, not yet.

[fredvs]

Ha, ok, because all the missing files (zipper, etc) where added.

[circular17]

Oh I see. Well you need to have zipper.pp in msegui\lib\common\fpccompatibility. With the mclasses tweak.

Yes, that's what I did yesterday. But if I well understand the first message of the discussion, there are problems with that solution, isn't it?

Not exactly. The problem comes if the file does not have mclasses after Classes in uses clause. If someone uses the file from FPC, it won't have mclasses for sure.

[circular17]

A first view of differences between classes and mclasses:

{ classesh.inc } TPersistent = class(TObject,IFPObserved)
{ mclasses.pas } tpersistent = class(TObject{,IFPObserved})
{ classesh.inc } FObservers : TFPList;
{ mclasses.pas } //    FObservers : TFPList;
{ classesh.inc } TComponent = class(TPersistent,IUnknown,IInterfaceComponentReference)
{ mclasses.pas } tcomponent = class(tpersistent{,IUnknown,IInterfaceComponentReference})
{ classesh.inc } function GetComObject: IUnknown;
{ mclasses.pas } //    function GetComObject: IUnknown;

So Martin removed some interfaces. Ok.

[rchastain]

Sorry to come a few late in the game but what demo/test are you trying to compil and that gives all the errors?

It's the MSE installer from MSEuniverse.

https://github.com/mse-org/mseuniverse/tree/master/tools/mse-installer

I suggested to use that project to experiment as an example (because I noticed that it uses zipper and also units like msegraphics, mseformatjpgread, mseformatpngread, etc).

[rchastain]

Not exactly. The problem comes if the file does not have mclasses after Classes in uses clause. If someone uses the file from FPC, it won't have mclasses for sure.

OK. I didn't understand correctly.

[fredvs]

https://github.com/mse-org/mseuniverse/tree/master/tools/mse-installer I suggested to use that project to experiment as an example

Ha, ok, I will jump into it tonight.

[rchastain]

Ha, ok, I will jump into it tonight.

To save your time, here is the whole project fixed (with some parts of the code put in comment).

mse-installer-202004181804.zip

There are two projects in it (mse-installer.prj and setup.prj). Both compile and "work" (open without crash).

By the way, there are very beautiful things in MSEuniverse.

[fredvs]

Ho, that will be very useful, I just load the prj now and there are tons of error messages.

Imho, this project is very old and is not up-tp-date with last msegui versions. Thanks, Roland, I will try with your file.

You are more than welcome to commit your fixes in mse-org/mseuniverse.

[rchastain]

You are more than welcome to commit your fixes in mse-org/mseuniverse.

Yes, when I am ready I will do it. For now, I try things.

[rchastain]

Some news.

I played with a MSEgui demo using the lNet library. After I made the changes to fpccompatibility folder, I can no longer compile the project:

Compiling ./lnet/lib/lmimewrapper.pp
lmimewrapper.pp(255,76) Error: Incompatible type for arg no. 1: Got "TBogusStream", expected "tstream"

Here is the line 255:

meBase64 : FEncodingStream := TBase64EncodingStream.Create(FLocalStream);

If I try to compile the same unit not in MSEide but in Geany, it compiles without any error.

[fredvs]

What fpc version, on what os? I dont have any idea what is INet library.

[fredvs]

but in Geany, it compiles without any error.

Huh, this one sorry I dont understand, do you use same compiler?

[rchastain]

Huh, this one sorry I dont understand, do you use same compiler?

Yes, it's the same compiler, but as I call FPC from Geany (and not from MSEide), the compiler uses the original units, and not the units that we have modified and included in MSEgui. You see the problem? The lNet library uses the FPC units that we modified and included in MSEgui.

[fredvs]

To save your time, here is the whole project fixed (with some parts of the code put in comment). mse-installer-202004181804.zip There are two projects in it (mse-installer.prj and setup.prj). Both compile and "work" (open > without crash).

@rchastain WOW.

I am totally impressed by the totally OOTB project that you have done. I did prepare lot of coffee for a long white night and, just copy your files in original project, compile it and it works-run directly at the first time, without changing anything!

Ha you are a real MSE-guru.

Well done Roland.

And yes, there are incredible gems there in MSEuniverse.

[fredvs]

@rchastain The project tools/mse-installer/setup.prj seems to me perfect as base for your idea for a installer. I would prefer this that using InnoSetup, who is great, but Windows only.

(But maybe change the original color...)

[fredvs]

the compiler uses the original units, and not the units that we have modified and included in MSEgui. You see the problem?

Not really.

Could you check with Project Option - Make - Show command line if it uses the same command than Geany?

[rchastain]

Not really.

Fred, it's very simple. If I compile from MSEide, modified units are in the path. If I compile from Geany, modified units are not in the path.

[fredvs]

Yes, I perfectly understand that but I dont understand if Geany uses the same command line as MSEide that the result can be different.

[fredvs]

Did you see last picture I added later in previous post?

[rchastain]

Fred my friend, I am tired. I will go to sleep. If you want, you can try it by yourself.

https://github.com/almindor/lnet

Try to compile the lmimewrapper unit in an empty MSEide project and (for example) in an empty Lazarus project.

Good night!

[fredvs]

Hello Roland.

Good night.

OK, I will try. About Geany, I did try to compile mse-installer.pas and it was OOTB, using the command line of MSEide:

But maybe I miss something.

Re-good night.

Fre;D

[fredvs]

Try to compile the lmimewrapper unit in an empty MSEide project

Yes, indeed, each unit that uses classes must add mclasses. Hum, that is a big problem...

I really hope that the Circular's Bridge will do miracles.