[Lazarus] Proposal for changing fpc version on the fly in the IDE

[patspiper]

On 22/08/13 19:36, Mark Morgan Lloyd wrote:
>
> I started off with a standard FPC binary installation circa 2.0, this 
> put the utilities in /usr/local/bin ** . Since then I've generally 
> built from source- in many cases I've had to since there wasn't an 
> up-to-date binary- and I've never had to explicitly tell the build to 
> use non-standard directories.
>
> So if you're now saying that I'm doing something wrong by- in some 
> way- overriding "correct" behaviour then I'm interested to know. 

I never said you were doing something wrong, although I am not sure what 
would happen if you uninstall your original FPC. Would the newer built 
from source versions still work? Moreover, if you install from trunk,  
then some of the unstable files will be used for all fpc versions. What 
I do is always build from source, and have several versions coexist 
without any possibility of conflict since the folders are completely 
separate.

> Otherwise, what you're suggesting is a significant change to FPC build 
> and I suggest you raise it with the compiler developers- it's not a 
> Lazarus issue.

I use standard building (from source) for FPC as if it were a new 
install, but just make sure each gets its own folder by specifying the 
INSTALL_PREFIX accordingly. So there is nothing that needs to be raised 
with FPC devs.

On the other hand, my proposal relates to being able to change the fpc 
version in the Lazarus IDE on the fly.
>
>> Furthermore, each version has its own fpc binary and tools in the 
>> usr/local/bin folder. They could be compatible or incompatible across 
>> versions. Thus it is better for each version to have its own set of 
>> folders.
>
> I've never seen any suggestion that this breaks backwards 
> compatibility, and if it does it should probably be raised as a bug- 
> at least so that it can be documented properly. In any event, as long 
> as fpc (etc.) knows what version of backend it's using then later 
> versions should be able to emulate older ones: I don't think anybody'd 
> be fool enough to try the other way round :-)

Would you trust using the fpc binary (not ppcxxx) and associated 
utilities of trunk for your production apps?

>
> ** On Linux. Solaris was lightly different, and of course Windows has 
> its own "best practice".
>
:)

Stephano