2009/5/16 Mattias Gaertner :

Let's assume, there's a team of developers working on the same project. The project uses some 3d party lib. It can be located anywhere on developer's machine. So relative paths for one developer, are not suitable for other developer's configuration.

Yes, it can be fixed, by forcing all developers to have the same directory structure, or by using lazarus packages . But is there any other way?

on Delphi it's resolved by declaring system environment variable, i.e: SOMELIB=c:\work\somelib
and the delphi's search path is declared as this
${SOMELIB}\

AFAIK, Lazarus uses internal codetool defines, like ${LazarusDir} $(TargetCPU) $(LCLWidgetType) and so on.
IDE does not support environment variables in search paths. Am i wrong here? if i'm right, how hard would it be to implement?

thanks,
dmitry

That's why there are packages.
Put the 3rd party lib in a package.
Packages can be anywhere on your disk.
Each developer need to open once the .lpk file. Then the IDE knows where to find the package on the machine. The next time a project needs the package with this name the IDE will find it. This information is stored in the lazarus config directory.

You can store a default path to the lpk in the lpi too. So when you distribute a package together with a project the package is found automatically.

Yes, it can be fixed, by forcing all developers to have the same directory structure, or by using lazarus packages . But is there any other way?

Of course.
And they don't even need to use the same package version.

A search path is seldom enough.

Mattias

A search path is seldom enough.

but, still, pachtes are welcomed?

> A search path is seldom enough. but, still, pachtes are welcomed?

I added a macro function $Env(name).

Mattias

thanks

That is exactly what Lazarus Packages was designed to solve! Lazarus Packages are a LOT more than Delphi Packages. Simply create a package for each 3rdParty component, or create a collective "our_3rdparty_package". Now reference that package as a requirement in your project. Now each developer simply needs to open and compile the package (so Lazarus knows where to find it). If it's a runtime package, it obviously doesn't need to be installed in the IDE.

Now simply open the project and lazarus will find all the related units from the 3rdparty package. It works brilliantly - *much* better than how it was done in Delphi IDE. The latter was a nightmare.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

But then the question arise : if I create one nice package for a suite of components, but user will use only one component from suite in his application , does it mean then his project will depend on *ALL* components of suite ?

I know that was and issue of adding component registration unit to the lpr file uses clause.This was later resolved AFAIK but still information about such dependency is bothering me. I have a suite of components , some of them in delphi have also additional run-time package. I would like to create only one Lazarus package to cover complete suite , because of dependency between them. In past there was a nightmare to rebuild it in Lazarus ,now it's a lot better (the problem was with recompilation of one component and checksum error) but one package definitely would solve future problems.

Boguslaw

Lazarus packages are usefull, but i don't want to use them for some projects.

Now each developer simply needs to open and compile the package (so Lazarus knows where to find it).

this is the step, i'd like to avoid.
all i want, is to specify paths and compile (whole project at once), rather than splitting into steps: package1, package2 ... packageN and then project itself.

I know, this needs to be done only once, because if package's sources're changed, IDE will detect it and recompile the changed package. And other project using package1, 2 .. N will not require to compile them again.

But still, it can be very annoying. For example, with the project itself, there might be a lot of small test applications based on the same libraries used, for each of them i'll have to specify packages dependency (again and again for each test). IMHO, it's easier just to copy-paste search paths.

My point view: the less IDE buttons need to be pushed - the better :)

thanks,
dmitry

2009/5/16 Bogus?aw Brandys :

If you only have on large packages, then your project will depend on that package. Smartlinking and disabling "Package Options > Usage > Add package unit to uses clause" should prevent all those units from being linked into your final executable.

I you want a project that say only depends on one component in that large package, then why not split each component into its own package.

For example:

Large3rdParty Package
- Component1 package
- Component2 package
- Component3 package

So now you have 4 packages. If your project uses all the components, then simply add "Large3rdParty Package" as a requirement to your project. If your project only uses "Component1", then only include "Component1 Package" as a project requirement.

I do this package hierarchy often in my projects. And the nice thing is you only need to include the last package in the hierarchy that fulfills your component requirements. I for example have the following.

FCL
|
tiOPF.lpk fpgui_toolkit.lpk
| |
---------------------------
|
tiOPFfpGUI.lpk

So if I create application that require FCL, tiOPF and fpGUI Toolkit, I only include the tiOPFfpGUI.lpk package in my project. If I need a console based application that talks one of your databases via tiOPF objects, then I only need to include tiOPF.lpk package in that project.

Lazarus Packages are very flexible and a real bonus to Lazarus! Also if any of those components have changed, I can simply recompile my project and any out-dated packages will be compiled if needed before the project is compiled.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

dmitry boyarintsev wrote

Lazarus packages are usefull, but i don't want to use them for some projects.

I can't see why??? I even compile projects that use lazarus packages from the command line (automated daily test suite for tiOPF project).

> Now each developer simply needs to open and compile the > package (so Lazarus knows where to find it). this is the step, i'd like to avoid.

But you only need to do that once, for the life of your lazarus install (lazarus profile directory).

I know, this needs to be done only once, because if package's sources're changed, IDE will detect it and recompile the changed package. And other project using package1, 2 .. N will not require to compile them again.

And now you are overlooking another BIG advantage of lazarus packages (which Delphi IDE suffers badly from and what you are trying to duplicate in Lazarus). If you have many projects relying on various components and you use unit paths instead of packages, you are going to have hordes of duplicate compiled units for the same component. The same .dcu files will littered all over your projects unit output directory, causing inconsistent versions of .dcu files and eating up lots of hard drive space.

Using packages, you only have one set of compiled units, no matter how many projects use those lazarus packages.

But still, it can be very annoying. For example, with the project itself, there might be a lot of small test applications based on the same libraries used, for each of them i'll have to specify packages dependency (again and again for each test).

No you don't have to! Have you heard of "project templates" or "new project add-ons". For example. If I want to create a fpGUI application, I go 'File > New .. > Project > fpGUI Application" and I'm done. Package dependencies are all setup for me already. I have the same thing for tiOPF project (and I often have loads of small tiOPF based applications).

You simply create one Lazarus add-on package that registers a new project type and you are done. I believe Lazarus IDE includes an example of such an add-on. If not, I can email you such a package or a URL where you can find the code for such a add-on. I think the "project templates" feature in the IDE can also define package dependencies - Mattias or Michael might be able to confirm this.

My point view: the less IDE buttons need to be pushed - the better :)

Agreed, developers are lazy by nature. :-) Hence the reason I use packages. You have to go "file > new" and then copy and past paths for each project. I simply go "File > New" ;-)

I think I should really write an article or extended documentation on Lazarus Packages. Clearly many developers don't know what it entails and how flexible it can be. And it's a vast improvement over Delphi Packages!!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

> Lazarus packages are usefull, but i don't want to use them for some projects. I can't see why??? I even compile projects that use lazarus packages from the command line (automated daily test suite for tiOPF project)

the answer is simple. Project should not be bound to any IDE. So it's easily portable, from compiler-to-compiler.
Currently the only thing binding a project ot Lazarus is .lpi file. That's used only to keep the search path list, this makes the project easily switchable to Delphi. Infact the project is built in both Lazarus and Delphi. No lazarus or delphi packages are used only the sources, filled with all possible .dcu, .o, .ppu, .bak files :) But it's not a problem at all.

Agreed, developers are lazy by nature. :-) Hence the reason I use packages. You have to go "file > new" and then copy and past paths for each project. I simply go "File > New" ;-)

But first it's necessary to overcome a lazyness and to learn about Project templates... It's too hard :)

thanks,
dmitry

The IDE automatically compiles required packages if needed, just like the compiler does for units.

If you have many test applications with many dependencies, why don't you use 'save project as'?

My point view: the less IDE buttons need to be pushed - the better :)

Mattias

dmitry boyarintsev wrote

the answer is simple. Project should not be bound to any IDE. So it's easily portable, from compiler-to-compiler.

You are confusing the point. Talking about IDE and then Compiler. They are separate things.

The projects I write with Lazarus IDE are *not* bound to Lazarus. I often switch to our remote 64bit linux server which doesn't have Lazarus installed. Yet I still compile all our projects with ease.

Our projects include the .lpi files, and have separate .lps files (the latter we discard at will and doesn't live in repositories). But those .lpi files are purely for Lazarus IDE - the same way that the Delphi IDE has .bproj files. These files are separate from the main "project" file which is .lpr (lazarus) or .dpr (delphi). The latter two are just renamed .pas files. So from the command line you can simply compile the .lpr file just like you would have done with a .pas file.

tiOPF is a project that works with the Free Pascal Compiler and the Delphi compiler. tiOPF currently supports the following: FPC 2.2.4, 2.2.5 (haven't tested 2.3.x recently but last time I did, it did work), Delphi 7, 2006, 2007, 2009.

So I would say Lazarus and Delphi can work together on the same source code.

But first it's necessary to overcome a lazyness and to learn about Project templates... It's too hard :)

It's really not that hard. I simply to an example add-on and modified it slightly for tiOPF and fpGUI projects. The new "project templates" feature in Lazarus IDE is even easier. Simply copy (yes the hard to use copy command) a template project into the "Templates" directory. There is one text file to give a discription of the new project which is rather easy to edit with any text editor.

So no, I do not consider it hard. Hey we are programmers after all - nothing is to hard. ;-) But honestly, it is not difficult to create project add-on or even simpler, using the new "project templates" feature.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

If you have many test applications with many dependencies, why don't you use 'save project as'?

some times i do use it, to save all the project's settings. but, it's something of psychology, i'm pressing 'New Project' and go to compiler options setting up searching paths.

It's a matter of habit, nothing else. New project starts with 'New project' menu item, not "Save as...". Though "Save as..." would definitely save a lot of time.

These files are separate from the main "project" file which is .lpr (lazarus) or .dpr (delphi).

Actually, we share .dpr files. It's easy for us, since we don't use VCL or LCL.

So I would say Lazarus and Delphi can work together on the same source code

God bless FPC and Lazarus teams! for {$mode delphi} and Code Tools.

So no, I do not consider it hard. Hey we are programmers after all - nothing is to hard. ;-) But honestly, it is not difficult to create project add-on or even simpler, using the new "project templates" feature.

It not hard for you or me. After all, i'm the only one in the team who's actually using Lazarus...
But then the time comes (and it WILL come), it would be easier to keep each .lpi search path properly set:
$Env(somelib)/
Rather than explain to the rest of the team how to use project templates, or that they don't have package installed.

thanks,
dmitry

P.S. $Env(var_name) is good, but imho $(var_name), is better.

On Sat, May 16, 2009 at 11:05 AM, dmitry boyarintsev

Actually, we share .dpr files. It's easy for us, since we don't use VCL or LCL.

Same here.

Rather than explain to the rest of the team how to use project templates, or that they don't have package installed.

Well with my years of experience with Delphi, I would say Lazarus IDE is a welcome sight. It makes component installation and package management a breeze. In Delphi IDE we had loads of unit paths, they had to be in a set order etc.. just a nightmare to setup.

Kudos to the Lazarus development team! :)

P.S. $Env(var_name) is good, but imho $(var_name), is better.

I disagree. Env() clearly shows that it is an environment variable and not any of the other built-in macros. Mattias made the right choice for Lazarus IDE.
It shouldn't make a difference to you anyhow - you simply "copy & paste". ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I disagree. Env() clearly shows that it is an environment variable and not any of the other built-in macros. Mattias made the right choice for Lazarus IDE. It shouldn't make a difference to you anyhow - you simply "copy & paste". ;-)

It's again, matter of Delphi compatibility. Delphi uses $(var_name). But it's really does not matter. I'll use it. Thanks again to Mattias.

ragards,
dmitry

On Sat, May 16, 2009 at 11:17 AM, dmitry boyarintsev

It's again, matter of Delphi compatibility. Delphi uses $(var_name).

Yes, but does Delphi IDE have built-in macros like Lazarus IDE? $(TargetOS), etc... Lazarus IDE needs need to distinguis between marcos and environment variable. I guess Delphi IDE doesn't (saying that, the last Delphi IDE I used was D7 which didn't).

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Yes, but does Delphi IDE have built-in macros like Lazarus IDE? $(TargetOS), etc... Lazarus IDE needs need to distinguis between marcos and environment variable. ?I guess Delphi IDE doesn't (saying that, the last Delphi IDE I used was D7 which didn't).

There should be no problems mixing both built-in macroses and environment variables.
Built-in macroses are prior.
So, if i declared environment variable, named TargetOS, and it cannot be treated properly by Lazarus, then it's clearly my problem, and i should rename the variable.
If $(var_name) is not found among built-in macroses, environment variables should be checked for var_name.

thanks,
dmitry

If $(var_name) is not found among built-in macroses, environment variables should be checked for var_name.

Why introduce an unneeded source of misunderstanding instead of clearly differentiating between EnvVars and macros?

S.

Mattias Gaertner ha scritto:

Fine! Is it possible to add also a macro function $BatchExt() ('.bat' in windows, '.sh' on linus, no idea on Mac)?

Can you give an example for this macro?

Mattias

Mattias Gaertner ha scritto:

Well, after compiling a project I need to execute a batch file on windows and a shell script on Linux. Using the Execute After Command of the IDE.

In my project folder I keep a .bat file and an equivalent .sh file, but every time I compile on one side I have to change the .bat to .sh and viceversa, so a macro of this kind could solve this problem using the command test$BatchExt().

Indeed, I just found a trick that solves my problem.

Using the command: test$TargetOS().cmd the IDE executes the script testlinux.cmd or testwin32.cmd for the respective platform.

So, the macro I asked for is not really so useful...

Using the command: test$TargetOS().cmd the IDE executes the script testlinux.cmd or testwin32.cmd for the respective platform. So, the macro I asked for is not really so useful...

Well, I think it is, even if it is not necessary. But it is much nicer to be able to name the files with their platform specific extensions than to have to use a common one.

S.

You can not execute a bash script directly. You must execute the shell and pass the script as parameter. A simple test.$BatchExt() would not work.
Do you have another example?

Mattias

Mattias Gaertner ha scritto:

Maybe I am missing something, but for me this works.

If I put the comand "$projpath()/test.sh" in the execution after section under the Compilation tab of the compiler options dialog, the script is executed each time the IDE lasts a build of my project. The same works if I use $projpath()/test.bat (with equivalent commands) under windows.

The script executes the following commands:

#!/bin/sh
strip myappname
ls -ls myappname >> myreport.txt
echo now >> myreport.txt
mv myappname anotherdirectoryname
rm *.o
rm *.a
rm *.ppu

Do you have another example?

no idea about other examples,

thanks