Hi,

I would like to know what the best way to work with FPC, Lazarus and 3rd libs. I will try explain myself:

Today I have three FPC versions (2.6.0, 2.6.3 and 2.8.1) and two Lazarus versions (1.0.1 and 1.1 (trunk))
The FPC trunk is only for test, so doesn't count.
Both Lazarus were compiled using FPC 2.6.3 and everything works. I have many 3rd libs (components) and they are compiled using FPC 2.6.3 too.

My "problem" is:
1- I want to have a stable Lazarus (1.0), compiled with FPC 2.6.2 and
stable Libs too (compiled with the same FPC version, ie. 2.6.2);
2- I want to have a Lazarus trunk, compiled with FPC 2.6.3 and Libs
too compiled compiled with the same FPC version;
3- I wont to change the libs package sources;

How can I have libs, compiled with different FPC version, but without change the output sources of libs and without have more than one copy of them?

Best regards,
Marcos Douglas

The second Lazarus must be started with another primary config path (command line parameter --pcp).
The second can use another compiler.
Compiling a project will automatically rebuild the packages.

You can change the output directory of the third party package to use the $(FPCVer) macro. For example
"lib/$(FPCVer)/$(TargetCPU)-$($TargetOS)".

Mattias

I already use the --pcp parameter to pass different configurations (packages, environment, etc).

The second can use another compiler. Compiling a project will automatically rebuild the packages.

Yep. Well, I thought there was a way to not recompile the libs to compile more faster, but Ok.

You can change the output directory of the third party package to use the $(FPCVer) macro. For example "lib/$(FPCVer)/$(TargetCPU)-$($TargetOS)".

Yep, but for this I need to change lib's sources. I won't to not missing the updates, but thanks anyway.

Regards,
Marcos Douglas

For my own libraries and other third party libs this is what I use

$(ConfDir)/lib/{LibraryName}/lib/$(TargetCPU)-$(TargetOS). Because I use a different -pcp directory it works very well me.

Yes, but as I said, to do this you need to change the lib package (source) to set the output files.
I do not want change the original libs sources.

Marcos Douglas

I fail to understand what you mean by that? You simply need to change the Unit Output Directory in each *.lpk you use, and add the $(FPCVer) part to the path. No other "source code" needs to be changed.

Regards,
- Graeme -

Marcos Douglas wrote

Yes, but as I said, to do this you need to change the lib package (source) to set the output files. I do not want change the original libs sources.

But why not? The *.lpk files hardly change. So if you get repository updates for those packages, there will not be any conflicts. Even if the *.lpk package changes (eg: new units was added), it should still not cause a conflict.

You have to change something, otherwise you will not be able to find a solution to your issue. The above is the bare minimum and least invasive change you can make.

Regards,
- Graeme -

I think the way I described should be made the default for all 3rd party libraries unless other more experienced developers think otherwise from their experience. Given the strictness of FPC with regards to compiler and build versions, I find it very useful and disk space is not so expensive now on general purpose computers.

Do you need to track some remote repositories that change often?

That is one reason for not wanting to use that method. I am sure Graeme can help you with some Git hook mojo when upstream changes :)

I know. When I said source I mean *.lpk - it is a source too, not?

You probably right, but problems can happen -- little problems -- like a file deleted, file renamed, etc. So I'll have to change the lpk anyway, manually.

You have to change something, otherwise you will not be able to find a solution to your issue. The above is the bare minimum and least invasive change you can make.

In that case I will prefer the Mattias' tip "Compiling a project will automatically rebuild the packages." so, I can use the original *.lpk and one output directory for each package, but if I compile them using other FPC version, they will automatically rebuild.

Regards,
Marcos Douglas

Marcos Douglas wrote

You probably right, but problems can happen -- little problems -- like a file deleted, file renamed, etc. So I'll have to change the lpk anyway, manually.

You should still not get any conflicts in the *.lpk files even if files was added, renamed or deleted. The only time you will get a conflict (and changes are very slim) is if upstream they changed the Unit Output Directory - something that pretty much never happens after it was set. They are different areas of the xml file (*.lpk file), so will not conflict.

Conflicts only occur if the same lines of code has changed locally and upstream.

Anyway, it's your choice.

Regards,
- Graeme -

Thanks for the good explanation. Well, I can change my choices... ;-)

Regards,
Marcos Douglas