Hi,

Many years ago when I still used Delphi, it was common in our development team to create our own patches for various components we used. We then placed those "fixed" units in a new path and add that path to the Delphi IDE (can't remember if the new path at to be on the top or bottom of the list).

Delphi would then read the newer unit instead of the older unit by default. No need to modify the original unit.

Is something like this supported by Free Pascal? If I place the copy of an existing RTL or FCL unit in a new path and add that new path as the first search path of FPC?

In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]

Not an answer, but a question about how this would work:

IIRC delphi has a equivalent of -Ur ({$IMPLICITBUILD OFF}). Were the _original_ components compiled with that?

Op 2010-06-17 10:39, Marco van de Voort het geskryf:

IIRC delphi has a equivalent of -Ur ({$IMPLICITBUILD OFF}). Were the _original_ components compiled with that?

It's been over 7 years, so the details are a bit fuzzy. If I remember correctly, Delphi used to like dumping all installed components (and thus *.dcu and *.bpl files) in a single directory (I think it was called Delphi7\Projects\Bpl\).

If your project then included a new *.pas files with earlier unit search path pointing to that new *.pas, it would recompile it and its *.dcu will be generated inside your project's output path, thus used instead of the original one in the Delphi7\Projects\Bpl path.

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

Well, it is hard to implement fuzzy details :-)

If your project then included a new *.pas files with earlier unit search path pointing to that new *.pas, it would recompile it and its *.dcu will be generated inside your project's output path, thus used instead of the original one in the Delphi7\Projects\Bpl path.

Were it third party or components that come with Delphi that you replaced?

If only the unit implementation changes, and you don't use inlines and you compile the unit with the same compiler flags, can this ppu be used instead of the original?

Mattias

Op 2010-06-17 10:51, Marco van de Voort het geskryf:

Well, it is hard to implement fuzzy details :-)

:-) I was simply asking if somebody tried that with Free Pascal - it wasn't meant as a feature request.

Were it third party or components that come with Delphi that you replaced?

I believe it was third party components only. But I would expect FCL to be considered a "third party" components.

I guess one way to find out if it works, is to give it a try and see how FPC processes search paths and if two paths contain the same unit, what does it do (which one takes preference), or does it simply halt compiling.

The reason I'm asking is, say I have a project that uses fcl-passrc, and in my project I implemented a new feature or bugfix to fcl-passrc (a requirement for my project to work), is there a way I can include that "fixed" unit in my project source so the end-user (developer) doesn't need to override the original fcl-passrc, and that fix/feature will only be limited/applied to my project that really needs it. Then hopefully in future FPC releases that fixes unit will become obsolete as the fix is included with FPC.

eg:
In MSEide, it included units for FPC 2.0.2 and 2.0.4 that the developer needed to copy over the official released versions to get MSEide to work. Maybe the idea we used in Delphi 7 could prevent having to overwrite the official *.pas files in such a case.

Anyway, I'll try it with FPC and report back how it goes.

Regards,
- Graeme -

Op 2010-06-17 11:13, Mattias Gaertner het geskryf:

If only the unit implementation changes, and you don't use inlines and you compile the unit with the same compiler flags, can this ppu be used instead of the original?

Yes, that's the point I'm trying to make. When we did this years ago in Delphi 7, it was basically small bug fixes in the implementation section. The interface section never changed.

Regards,
- Graeme -

Op 2010-06-17 11:13, Mattias Gaertner het geskryf:

If only the unit implementation changes, and you don't use inlines and you compile the unit with the same compiler flags, can this ppu be used instead of the original?

It worked! For implementation sections bug fixes at least. :-)

Below is the output of "Lazaras IDE > Project Options > Show Options". Note the -Fu/tmp/fixes which contained a new version of fpg_edit.pas. When I compiled the project the original fpg_edit.o and fpg_edit.ppu inside /home/graemeg/programming/fpgui/lib/x86_64-linux/ did not change, instead the newer *.pas was compiled and its .ppu was created inside my projects unit output directory - overriding the original.

-MObjFPC -vewnhi @debug_build.cfg -Fi../ -Fu../ -Fucomponents/ -Fu/tmp/fixes/ -Fu/home/graemeg/programming/fpgui/lib/x86_64-linux/ -Fu/opt/lazarus/packager/units/x86_64-linux/
-Fu/home/graemeg/programming/3rdParty/tiOPF2/Source/Compilers/FPC/lib/x86_64-linux/ -Fu. -FUunits/x86_64-linux/ -FE../../Bin/x86_64-linux/ -otutoradmin -dLINK_SQLDB_IB

So it works for external code (not included with FPC). I'll now try replacing a FCL or RTL unit as see what happens. Though somehow I'm not as optimistic as before. ;-)

Regards,
- Graeme -

In our previous episode, Mattias Gaertner said:

I don't know if and how exactly this works.

Anyway, I'll just list some points that I know about the subject, maybe one of the other devels will correct any mistakes and/or enhance stuff.

* recompiling is done based on source timestamps and for .ppu's matching CRCs of the interface section.
* one ppu/dcu is not the other due to the recompile behaviour modification settings (-Ur see below), which can force "never recompile this .ppu" automatically.
* Contrary to Delphi, FPC also recompiles when it detected modified .incs
* the makefile parameter RELEASE=1 afaik also enabled -Ur and this is done for releases. So behaviour may differ between snapshot and release. God knows what 3rd party builders and the various *nix packagers do.

The recompilation behaviour is determined:

* -Ur (FPC)
* {$implicitbuild on/off} which is think is a .dpk only directive
* -Z "enable never build" dcc32 cmdline opt.

which all do the same thing, they allow to set a "don't recompile on source changes" flag to be set in the .ppu/dcu.

However it is not a matter of simply adding a feature here. Recompilation behaviour is a double edged sword:

- disable automatic recompilation (e.g. -Ur everywhere), and advanced users can not do this kind of tricks
- enable it, and all newbies "can't find unit system"
- then there is the matter of the .inc recompilation. FPC source a lot of .incs and all the names of these .inc files would be "forbidden" for users if the FPC distro was not compiled with -Ur.

Personally I don't like such schemes (also on Delphi) because while disciplined users can/may be able to make them work if they are very careful, it is totally unsupportable for general consumption.

And, as said, there are (support) consequences to disabling -Ur.

Op 2010-06-17 11:13, Mattias Gaertner het geskryf:

If only the unit implementation changes, and you don't use inlines and you compile the unit with the same compiler flags, can this ppu be used instead of the original?

So far so good. I managed to successfully replace ibconnection.pas which is part of the fcl-db code.

All I had to do, was copy the ibconnection.pp to the /tmp/fixes directory and apply the fixes/change there. Add /tmp/fixes as the first Unit Path in the Lazarus Package that uses fcl-db. The Lazarus Packages was set to "automatically rebuild as needed". After a lazarus package recompile, a new ibconnection.[o|ppu] was created in the lazarus package output directory (lib/x86_64-linux/). When I then recompiled my project that uses that lazarus package, it too was linked with the newer ibconnection and I could see the changed behaviour in my application when run.

I also tried adding -Fu/tmp/fixes/ in the ~/.fpc.cfg but for some reason that did not make any difference. The units in /tmp/fixes was not recompiled. I had to add the new path in the Lazarus Package (*.lpk) or project itself.

NOTE:
I haven't attempted to modifying a *.inc file yet, only a *.pas or *.pp that doesn't contain include lines.

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

Of a snapshot or of a release?

Op 2010-06-17 12:01, Marco van de Voort het geskryf:

Of a snapshot or of a release?

FPC 2.4.1 fixes branch from repository. Compiled two weeks ago with the following script.

---------------------------
#!/bin/bash

COMPILER=/opt/fpc_2.4.1/x86_64-linux/bin/ppcx64

cd src
make all PP=$COMPILER
make install INSTALL_PREFIX=/opt/fpc_fixes_svn/x86_64-linux/ PP=$COMPILER ---------------------------

As far as I know the RELEASE define was being set when I compiled the FPC itself - automatically managed by the makefile.

That is probably why the newer "fixes" path in the ~/.fpc.cfg did not make any difference - not 100% sure. Either way, it's easy enough (and my preference) to rather add the overriding new fixes path to whichever Lazarus Package or Project needs it. All other projects still use default FPC units.

Regards,
- Graeme -

I am using this copy-to-my-custom-dir-method for some fpc packages (eg. chm) and for some lcl units.

Regards
Žilvinas Ledas

The solution that I use is to rename the unit slightly, like I am improving OpenSSL.pas, so I renamed it to MyOpenSSL.pas to avoid conflicts. Once the changes are merged and released I will rename my uses clauses back to OpenSSL.

Can be very annoying if the problem involves lot's of units, but for simple cases works fine.