Hi, is there a way to setup unit search paths per platform?.

I usually develp for Linux and Windows, and some times, I use units that can't be accessed using the same relative paths on both platforms.

For example, on Linux I use:

../synapse

To let the compiler find units from Synapse library.

On Windows, the synapse directory is installed on ../../synapse, for example.

I would be nice to have conditionals or build modes for each platform.

Regards,

I use Project Options-> Build Mode
But i dont now how to make it autoswitch, maybe by using "In Session".

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110909/6b22751b/attachment.html>

Leonardo M. Ram? wrote

Hi, is there a way to setup unit search paths per platform?.

I would imagine it is possible in Lazarus IDE. It sure is in MSEide, or even via the fpc.cfg file. So you have many choices in how to do it.

Great!, from now on, I'll use this method.

Well, too fast.

The problem with this approach is that I also need to add the paths to Lazarus project options if I want to use ctrl+space to show class methods and properties.

I used also extrafpc.fpc

#IFDEF mycondition
#WRITE Compile for mycondition
-FuMypath
#ELSE
-FuMypath
#ENDIF

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110909/d5516d7d/attachment.html>

Have you tried the Lazarus package 'laz_synapse.lpk' of Synapse?

It seems a bit outdated, but that can be remedied easily: Open the package file 'laz_synapse.lpk'. In the package editor / More / Show missing files. This will show a dialog with two files. Click to remove these files.
Then compiling the package should work.

I will ask Lukas to update the package.

On Windows, the synapse directory is installed on ../../synapse, for example. I would be nice to have conditionals or build modes for each platform.

You can do that with the Lazarus trunk version.

http://wiki.lazarus.freepascal.org/Macros_and_Conditionals#Conditionals

For example:

if TargetOS='win32' then
  UnitPath := '../../synapse'
else
  UnitPath := '../synapse';

Mattias

The active build mode is stored in the session.

Set Project Options / Session / Save session .. / Save lps in project directory.

Now you have one session file per machine.

Mattias

With Lazarus trunk adding paths to fpc.cfg should work.

Mattias

Synapse was just an example, I use many other libraries in different directories.

Thanks for this.

I just tried that and it doesn't work. I'm using rev. 32233M

BTW, why the "build mode" ignores the "macro value" typed? http://wiki.lazarus.freepascal.org/Macros_and_Conditionals#Add_a_release.2Fdebug_mode

The build mode uses the "clicked parameters" in IDE not the typed in "macro value", right? So, why the "macro value" exists?

Marcos Douglas

We all do.

And fiddling around with search paths gets especially annoying when working together with other people. That's why there are packages.

Mattias

What do you mean with "clicked parameters"?
The "macro value" is the value you get when you use the macro, e.g. in a search path.

Mattias

Fixed in 32240.

Mattias

Sorry... To "clicked parameters" I mean 'Compiler Options'>'Linking'> |-Xs, -g, -gl, etc | , ie, the CheckBoxs on the IDE.

The "macro value" is the value you get when you use the macro, e.g. in a search path.

For example:
If I set a macro " MyMacro | -O2 " (name | value) and click in "Show Options" I see:
-MObjFPC -Scghi -CX -O1 -Xs -XX -vewnhi -l
bla bla bla
-FE..\bin\ $MyMacro -dLCL -dLCLwin32

The value -O2 was ignored but all parameters "clicked" will be used.

Lazarus 0.9.31 r31914 FPC 2.5.1 i386-win32-win32/win64

Marcos Douglas

Maybe you forgot the brackets?

$(MyMacro)

The value -O2 was ignored but all parameters "clicked" will be used. Lazarus 0.9.31 r31914 FPC 2.5.1 i386-win32-win32/win64

Mattias

See the attachment, please.
Doesn't matter if I put, in "Build macros">"Conditionals": $(MyPackageOptions)
OR
$MyPackageOptions
OR
nothing...

The result is the same, ie, the options that I chose using the IDE for each 'Build Mode'

Marcos Douglas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: printscreen.jpg
Type: image/jpeg
Size: 76931 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110909/46264c98/attachment-0001.jpg>

Oh, ok, I see now.
I forgot the brackets AND I said "Build macros" but the right is "Other">"Custom options".

So, I have to uncheck all options in "linking">"debugging": -gl, -gh, etc because these options checked are used... not my "Macro Values" as I thought.

Marcos Douglas

Mattias Gaertner wrote

You can do that with the Lazarus trunk version. http://wiki.lazarus.freepascal.org/Macros_and_Conditionals#Conditionals For example: if TargetOS='win32' then UnitPath := '../../synapse'else UnitPath := '../synapse';

I wonder if I could ask a silly question. I think a lot of us probably have personal conventions as to how we lay out directories etc., for example I copy the FPC sources into /usr/local/lib/fpc/x.x.x/fpcsrc.

Do any of the configuration files implement a backtick or similar, so that an external script or program in some suitable language can deduce parameters based on local conventions?

The conditionals have a different syntax than the search paths. Search paths are file paths separated by semicolon and macros have the form $(MacroName) or $MacroFunction(Parameters). For example:

lib/$(TargetOS)

Conditionals have a pascal like syntax, with variables, statements and expressions. Here is an example how to use the macro TargetOS in the conditionals:

if TargetOS='win32' then ;

Custom options are similar to search paths when it comes to macros. The custom options are for anything you can not achieve with the dialogs. They are simply appended to the options passed to FPC, which normally means they have higher priority for FPC.

So, I have to uncheck all options in "linking">"debugging": -gl, -gh, etc because these options checked are used... not my "Macro Values" as I thought.

Yes, the checks are used, combined with the custom options and passed to FPC.
Each build mode stores the checks, so you don't need put '-gl -gh' into macro values. Just check the options in the dialog.

Mattias

That was one of the reasons, why the Lazarus packages were created. The package maintainer can define the directory layout of his package, and the user can freely put the package anywhere on the file system.

The above static connection between a project and the synapse sources is unnecessary with Lazarus. The '../../synapse' and the '../synapse' can be computed by Lazarus automatically. Just open the laz_synapse.lpk in the IDE and click 'Use / Add to project'. The above paths are automatically computed. No need to use conditionals, macros or edit search paths.
Copy the project and synapse to another computer and/or OS. Again: No need to adapt the search paths. Just open the laz_synapse.lpk and the project once.

Same for the FPC sources.

The compiler needs search paths. The IDE creates them for you.

Do any of the configuration files implement a backtick or similar, so that an external script or program in some suitable language can deduce parameters based on local conventions?

Well, you could define environment variables and use them in fpc.cfg and Lazarus. But these are mostly for linker paths and options or for instantfpc.

Mattias

I understood everything. Did tests and everything works really good. The Lazarus is a great IDE.
Thanks for this lesson about Macros, Conditionals and Custom options.

Marcos Douglas

You really should not do this. I though you would know that when you add the synapse package as a dependency to your application, the path will be added automatically. So it doesn't matter where the package is installed.

I wrote a blog-post about this last Friday, it's not really a how-to, but maybe you can find more information there:
http://www.lazarussupport.com/lazarus/weblog/project_settings_in_delphi_and_lazarus

Joost.

Correct.
But in this case: the synapse package is broken and I did not receive an answer yet.
Maybe we can provide a synapse package on lazarus-ccr?

I wrote a blog-post about this last Friday, it's not really a how-to, but maybe you can find more information there: http://www.lazarussupport.com/lazarus/weblog/project_settings_in_delphi_and_lazarus

Mattias

On Mon, Sep 12, 2011 at 7:39 PM, Mattias Gaertner <

wrote: Maybe we can provide a synapse package on lazarus-ccr?

Not agree, you can fix it and add the patches/fixes to lazarus-ccr for temporary.

Porting code from other that already support you main project like Lazarus is bad idea, because i think the original maintainer is the best one to improve his code.

For that someone like GIT, in GIT you can fork the code, make fixes, and keep it up to date from the original code.

Best Regards

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110912/100fe6e0/attachment-0001.html>

It is about the lpk, not the code.
If Lukas does not work with Lazarus, then Lazarus users should help him maintaining the lpk.
If the lpk can not be updated in the original distribution, then maybe the lpk can be put on the lazarus-ccr to make it easier for Lazarus users to use Synapse.

For that someone like GIT, in GIT you can fork the code, make fixes, and keep it up to date from the original code.

Mattias

I wrote a blog-post about this last Friday, it's not really a how-to, but maybe you can find more information there: http://www.lazarussupport.com/lazarus/weblog/project_settings_in_delphi_and_lazarus

IMO everything boils down to the different package management, in Delphi and Lazarus. While Delphi relies on the Windows registry, Lazarus relies on its own package registration - what (currently) requires to rebuild the IDE for every installed (design time?) package.

DoDi

You are mixing two things up here:

1. You need to rebuild Lazarus everytime you install a new package, because Free Pascal does not yet support dynamic packages (or to be more correct: it's in a very, very rudimentic state). And dynamic packages themselves don't need the uses the Windows Registry to store its known packages, true, but Lazarus basically does the same for its installed packages in its XML files that are stored in e.g. %APPDATA%\lazarus or ~/.lazarus. The Lazarus variant is cross plattform though and Lazarus will continue to use a mechanism like this when dynamic packages become a reality for FPC.

Regards,
Sven

2. Delphi uses the Windows Registry to store its known packages, true, but Lazarus basically does the same for its installed packages in its XML files that are stored in e.g. %APPDATA%\lazarus or ~/.lazarus.

The difference becomes obvious with multiple Lazarus installations. Where multiple Delphi versions share packages (causing trouble), every Lazarus installation must be configured explicitly.

DoDi

Different Delphi versions don't share packages. The "known packages" key in the registry is different for every version and also the IDE can't load packages that were compiled for another version the only exception being Delphi 2007 which has the same binary layout as Delphi 2006. The common packages "rtl", "vcl", etc. also all have the compiler version in it. E.g. "rtl170.bpl" for (I believe) Delphi 2007.

That the default of Lazarus isn't that user friendly especially for beginners is another topic...

Regards,
Sven

Every Delphi version uses it's own package version, but it's known that installation and deinstallation has side effects on other Delphi installations.

DoDi

I had no problems when I installed Delphi 5 in parallel to Delphi 6 at work. Also not when I removed it again later and again later installed Delphi 2007...

Regards,
Sven