[fpc-devel] FPC/Delphi/FastMM4/TopMemory speed test

[Sven Barth]

Hi!

On 18.07.2010 11:34, Adem wrote:
>   On 2010-07-18 11:41, Mattias Gaertner wrote:
>> /usr/lib/fpc/2.4.1/units/i386
>>
>> Translate this to some windows paths you like and adapt your fpc.cfg.
> Quick question. I took a look at 'Installing Lazarus' [
> http://wiki.lazarus.freepascal.org/Installing_Lazarus ] and all the
> examples for paths have no spaces in them.
>
> Indeed, in my fpc.cfg, all paths are spaceless, such as
> 'c:\Lazarus\fpc\2.4.3/units/$FPCTARGET/'
>
> There's also a special warning against them in the FAQ: "3. Check if the
> compiler *installation path has spaces* in it. *Make sure it doesn't!*"
> [ http://wiki.lazarus.freepascal.org/Lazarus_Faq#I_can.27t_compile_Lazarus ]
>
> Is there a fundamental (still valid) reason for not being able to have
> it something like "c:\Program Files\Lazarus\fpc\2.4.3/units/$FPCTARGET/"
> at least under Windows?
>
> It goes against everything we're accustomed to these days.
>
> What would it take to remove that limitation, I wonder?

If I remember correctly it's not a limitation of FPC itself, but more of 
the Unix tools (make, etc) it's using. They seem to dislike spaces in paths.

Also using "c:\Program Files" for Lazarus is a bad idea, because that 
directory is write protected by definition and you still need to rebuild 
Lazarus if you install a package or the LCL if you patch something.

>> Keep in mind that Lazarus and FPC are separate things and that only the
>> windows installer puts fpc in a sub directory of the lazarus
>> directory.
> OK. I usually do my development under Windows and when I have to compile
> on Linux, I install Lazarus/FPC from a package and not worry about its
> internals.
>> You can easily use one lazarus with several fpcs and they can share
>> the same fpc source directory.
> I am assuming this is optional. I.e., you can alson opt not to share a
> common source directory as well.
>>> I think the reason why they didn't is because both installations share
>>> the same data folder i.e. C:\Users\$username\AppData\Local\lazarus
>>>
>>> Hence, both the x86 and x64 versions share the information stored under
>>> that folder --which screws up things.
>>>
>>> A better solution, IMO, would be to use both the patform and version
>>> numbers; so that workdirs become:
>>>
>>> C:\Users\$username\AppData\Local\lazarus\0.9.29\win32\2.4.0
>>> C:\Users\$username\AppData\Local\lazarus\0.9.29\win32\2.4.3
>>> C:\Users\$username\AppData\Local\lazarus\0.9.29\win64\2.4.0
>>> C:\Users\$username\AppData\Local\lazarus\0.9.29\win64\2.4.3
>>>
>>> etc.
>>>
>>> This way, I can have several different versions live under the same
>>> $username.
>> Feel free to do so.
> But, that would mean also altering how Lazarus behaves (under Windows at
> least). I doubt if I could get past the inertia.
> Not knowing who to talk to is immensely discouraging.

Do you know about the --primary-config-path=DIR parameter that you can 
pass to the Lazarus executable? That way you can specify the directory 
where the IDE is saving the user's configuration files. I'm using it 
successfully to run multiple versions parallel on Linux (but it works in 
Windows, too, but you might want to adjust the shortcuts for this). I 
already asked about a "multiple version aware" installer here: 
http://bugs.freepascal.org/view.php?id=15813

>>> One more thing: Lazarus, when uninstalled, removes neither its install
>>> folder, nor its workdir; which it should.
>> I don't know the internals of the windows installer.
>> Maybe Vincent knows.
> My ideal installer would also be able to download only the sources and
> build them locally --instead of downloading a much bigger binary package.
>
> I wonder if this would be possible. or even generally desirable.

I prefer it not to uninstall my configuration data (or it should ask 
whether that should be done), because if I install a newer version I'd 
need to reconfigure the IDE to my likings again (templates, coding style 
options) and to open every package I used once again (which is getting 
on my nerves VERY much).

Regards,
Sven