How to select exact FPC and Lazarus commits when creating a new Lazarus build?

[vfclists]

How to select exact FPC and Lazarus commits when creating a new Lazarus build?

Years ago, I whined about FPC compiler fixes causing build failures because the library upgrades are not unbundled from the compiler upgrades, and as a result I had to develop a script for compiling Lazarus that enabled me to specify the exact commits for both FPC and Lazarus.
It took some doing because I had to match the SVN tags with Git commits.

Now the problem is back again after Is "FPC_FULLVERSION" not configured properly in some builds? in which upgrades to fpimage.pp bundled with FPC 3.2.3_fixes conflict with BgraBitmap 11.5.8.


So if I'm using fpcdeluxe for instance how can I specify the commit of FPC compiler and  the commit of the FPC libraries separately, because the FPC libraries snapshot I need to build should be the exact ones that came with Lazarus 3.0.0, ie  fpc-laz_3.2.2-210709, even if Lazarus and the FPC compiler have moved on.

Even if they are bundled together knowledge of the exact commits should make it possible to just copy out the different compiler and library directories and combine them for the new build. That is one thing made easy by Git.

Can we also have the discussion about the separation of compiler and libraries again? It is an old discussion and I'm not sure whether it was on this forum or the mailing list.

[marcov]

If you want granularity, use releases and packages that specify they run on those release.

For development versions (including fixes branch), you must make do yourself.

Unbundling won't happen, the situation is complex enough, and not THAT hard to handle with 2-3 years between the average FPC release.

[vfclists]

If you want granularity, use releases and packages that specify they run on those release.

For development versions (including fixes branch), you must make do yourself.

Unbundling won't happen, the situation is complex enough, and not THAT hard to handle with 2-3 years between the average FPC release.

The problem is knowing if the compiler itself depends on some parts of the upgraded libraries which I don't think it should, at least not fpimage.pp which is an image library.

In this case I should be able to revert fpimage.pp and all other files packages which depend on it back to the one that came with Lazarus.

Adopting another tack - if I am building fpc.exe and its associated ppcXX.exe files, how can I check which files in what directories it depends on? Are they specified in the make files, or output in the build log?

I assume that from that info I will be able to tell which library files I can revert safely.

[marcov]

The problem is knowing if the compiler itself depends on some parts of the upgraded libraries which I don't think it should, at least not fpimage.pp which is an image library.

But the opposite might be true. A (minor) dialect change in the compiler might affect fpimage.pp.

Nothing could have protected you against the issue with bgrabitmap, except sticking to only formally released versions. Between that, versioning and compatibility is fluid.

I know, because I probably caused it.

Adopting another tack - if I am building fpc.exe and its associated ppcXX.exe files, how can I check which files in what directories it depends on? Are they specified in the make files, or output in the build log?

There is no fine grained registration of such dependencies that you could mine for such knowledge. It simply is not there.  Development versions are make it up as you go, and things are a bit more synced with releases.

That's all there is. Period.

[Thaddy]

The compiler itself does not depend on libraries.