If you are using different Lazarus versions but with same components and packages, how would you organize separate build directories for the different versions, but same source location.

eg. say I am using fpc 2.2.4/ lazarus 0.9.28, fpc 2.4.0 / lazarus 0.9.29 and fpc 2.5.1/ lazarus 0.9.29

All though the package source files would be in one place (with necessary ifdefs for compiler and lazarus versions) I would like the units to go into say lazarus_0928_224/components/package_name_dir, lazarus0928240/components package_name_dir, lazarus0929251/components/package_name_dir.

Would I have to configure that in the separate IDEs, or in the package source files themselves?

There are many ways.
For example use one lazarus config directory for each version combination and make all package output directories read only. Then the IDE will put the ppu files into the config directory.

Mattias

Can this be achieved via macros?

For instance I have just posted a blog article on FPC/Lazarus compilaton at http://devblog.brahmancreations.com/content/build-scripts-for-installing-freepascal-and-lazarus-from-source, and what I want to do is to have the build_name variable as available to the IDE.

e.g if a lazarus build is named lazarus_0920_27001, I would like to use a macro based on the package name as well as the lazarus build name, so the compiler knows that units for zeoslib for instance go to directory /components/lazarus_0920_27001/zeoslib.

Even if the package sources must be modified that should be a minor problem.

Surely something like that must be possible.

I think it would also solve the problem of backporting packages made for fpc 2.5.1/lazarus 0.9.29 to the 0.9.28 and even the 0.9.26 series as it is extremely unlikely that they depend on language features only present in fpc 2.5.1.

Delphi developers are still producing code compatible with Delphi 7. Delphi 7 still appears to be the reference platform for Delphi development.

I am looking at
http://wiki.lazarus.freepascal.org/IDE_Macros_in_paths_and_filenames and I am considering using a combinatin of PrimaryConfigPath and package name to set the output directory.

- *Package macros* - these can be used in the fields of a package. For example in the search paths of a package. To use them elsewhere give a package name as parameter.
- *PkgDir()* - macro function for the directory (location of the .lpk) of a package ID given as parameter
- *PkgIncPath(id)* - macro function for the include path of a package ID given as parameter
- *PkgOutDir(id)* - macro function for the output directory of a package (e.g. where the ppu files are created)
- *PkgSrcPath(id)* - macro function for the source path (unit path + src path) of a package ID given as parameter
- *PkgUnitPath(id)* - macro function for the unit path of a package ID given as parameter

However there doesn't seem to be a macro for the package name itself in the package related macros. Can NameOnly(xxx) be applied to one of the above macros to obtain the package name referring to "packagename.lpk"? As packages have their own directories, I might settle for a macro to retrieve the last element of the directory so that ..\components\componentdir produces componentdir. I want to avoid having to edit the packages themselves, or just edit them in one place.

I'd like to use a combination of ConfPath or PrimaryConfigPath or the FallBackOutputRoot to handle the issue.

Something like
PrimaryConfigPath\NameOnly(packagepath)\lib/$(TargetCPU)-$(TargetOS) would be ideal.

Do ConfPath and PrimaryConfigPath refer to the same thing?

?
?

Frank Church hat am 14. Juli 2011 um 10:11 geschrieben:

?
There is no macro to make directories read only.?
?
?

?
The solution I gave puts the package files in
$(PrimaryConfigPath)/lib/$(PkgName)/something, for example /components/lazarus_0920_27001/lib/zeoslib
?
The 'something' depends on a few things. Someone said that there is a bug in some cases.?
?
?

?
If you want to change the lpk files, then you can of course specify whatever you wish.?
?

However there doesn't seem to be a macro for the package name itself in the package related macros.

?
I added a PkgName.
?

?
That's almost the default for read only packages. Why not simply use the default? ?

Do ConfPath and PrimaryConfigPath refer to the same thing?

What is ConfPath?

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110714/044cd01c/attachment-0001.html>

2011/7/14 Mattias Gaertner

Your solution did not indicate that an every package would have its own directory created for it under the PrimaryConfigPath, I thought they would all be dumped into a single directory.

Is it avaiable in 0.9.30 fixes? Are some of the new 0.9.31 backported to fixes?

I meant ConfDir and PrimaryConfigPath

Is it possible to create new user defined macro variables for the IDE?

Thanks

?
?

Frank Church hat am 14. Juli 2011 um 11:24 geschrieben:

?

?

?
That would be a Delphi mess. Separate output directories is one of the key features of the Lazarus package system.?
?
?

?
No.?
?
?

Do ConfPath and PrimaryConfigPath refer to the same thing?

I meant ConfDir and PrimaryConfigPath

?
Yes. ?
?

Is it possible to create new user defined macro variables for the IDE?

Projects and packages can define build macros.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110714/5568c92d/attachment.html>

And that can cause it's own set of headaches. Yes it saves on disk space because all projects using a package, use the same set of *.ppu files. But changing a compiler parameter or compiler define in a project doesn't apply to any of the packages - so you can get very undesirable results.

The other problem being that sometimes Lazarus doesn't detect unit changes and doesn't "auto" recompile those related packages. Also causing huge frustration.

I use to be a huge proponent for Lazarus Packages, but lately use macros (for defining differing paths on various systems), and more importantly, use a single output path for each project target. This solving all the problems listed above.

Regards,
- Graeme -

?
?

Graeme Geldenhuys hat am 14. Juli 2011 um 11:56
geschrieben:

No, it needs more disk space, because you have several output directories per package, .e.g. targetcpu-targetos.
?
?

because all projects using a package, use the same set of *.ppu files. But changing a compiler parameter or compiler define in a project doesn't apply to any of the packages - so you can get very undesirable results.?

AFAIK it is quite the opposite.
If all project options would be applied to all packages, that means applying options to code you have not written, you can get very undesirable results. For example there is a bug in fpc 2.4.4 under OS X that when you apply range checking to the IDE, it will fail with a strange error message. With separate options you can apply the -Cr only to your project. The same is true for many optimizations and debugging flags.? ?
The main idea for separate output directories is that you can be sure that the package units are compiled with the options the package developer tested it.? ?
?

The other problem being that sometimes Lazarus doesn't detect unit changes and doesn't "auto" recompile those related packages. Also causing huge frustration.?

You told so once and said you would tell me how to reproduce it once it appears again. But I didn't receive no such mail. Now you write again that the IDE is buggy - again without any clue.
This is not helpful.
?
?

There are many ways to maintain your code base. It is good that the IDE supports a lot.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110714/ba118c00/attachment.html>

Mattias Gaertner wrote

> And that can cause it's own set of headaches. Yes it saves on disk space No, it needs more disk space, because you have several output directories per package, .e.g. targetcpu-targetos.

I think you missunderstood my statement. I meant that using Lazarus Packages allows you to save on a bit of disk space. So if 10 projects are using the LCL package, you only have one set of target *.ppu files for the LCL package.

AFAIK it is quite the opposite. If all project options would be applied to all packages, that means applying options to code you have not written, you can get very undesirable results.

Here is an example:
I have a project that uses 'fpgui', 'onguard' and 'tiopf'. If I compile each of those libraries with unoptimized and very verbose compiler settings - that is helpful while developing and for debugging. But now I want to generate a release build of my project. I can't just toggle the release build settings in by project settings, because those will not be applied to the 3 libraries (lazarus packages) I use. So I have to individually change the settings for each of those 3 packages and recompile them, then recompile my project.

Whereas if I used a single unit output directory, my project compiler settings will be applied to all source code (even the 3 libraries I use) when I include the -B compiler parameter. Now ALL source code will have the optimized "release build" compiler settings applied to them. One change of compiler settings and one re-compile.

The main idea for separate output directories is that you can be sure that the package units are compiled with the options the package developer tested it.

I am the package developer and the project developer. So I guess my use case must be unique then [though I doubt that].

Yes, and I run the Lazarus IDE via the command line (as requested) for a week without any new information to report. The issue is not instantly reproducible, so it is rather difficult to be more "helpful" with the bug report.

There are many ways to maintain your code base. It is good that the IDE supports a lot.

+1
That was the whole point of my post. You stating that "Lazarus Packages" is the saviour compared to Delphi unit paths is not always 100% correct. Depending on use cases, either method can be the "ideal method" of working with your code.

Regards,
- Graeme -

?
?

Graeme Geldenhuys hat am 14. Juli 2011 um 12:39
geschrieben:

True.
?
I compared to common Delphi setting of having one global output directory.? ?

You can define a project macro and use that in each package custom options.? See here ?
http://wiki.lazarus.freepascal.org/Macros_and_Conditionals#Add_a_release.2Fdebug_mode ?
Using build modes you get a button in the IDE tool bar, so switching release/debug mode is just a mouse click away.
The -B option is automatically applied by the IDE as well.? ?
?

It's not unique. There is no question that a one-man-show makes the work flow very simple.
But in a collaborative environment you need some rules. ?
?

If it so difficult to reproduce, why is it a "huge frustration"? It is a huge frustration to read such mails.?
?
?

[...]

?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110714/b698593f/attachment-0001.html>

2011/7/14 Mattias Gaertner :

Hi Mattias,
I tried this (see attachment) but didn't worked. The IDE ignored the parameters.

My environment is Lazarus 0.9.30.1 r31020 FPC 2.4.5 i386-win32-win32/win64

Marcos Douglas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: options.jpg
Type: image/jpeg
Size: 58550 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110714/bbd9f8e4/attachment-0001.jpg>

These macros do not works in Lazarus [0.9.30.1] only from the version [0.9.31]?

Marcos Douglas

Mattias Gaertner wrote

I compared to common Delphi setting of having one global output directory.

Then I don't do it like Delphi either. I have a output directory per project and then per target platform inside that, not one huge output directory as was done in Delphi 7.

You can define a project macro and use that in each package custom options. See here http://wiki.lazarus.freepascal.org/Macros_and_Conditionals#Add_a_release.2Fdebug_mode

Thanks, I'll take a look.

If it so difficult to reproduce, why is it a "huge frustration"?

Because when it happens it is unexpected. So I probably waisted about 40 minutes to an hour debugging something that it solved simply by forcing a recompile of all units.

It is a huge frustration to read such mails.

:-)

Regards,
- Graeme -

Yes.

Mattias

So, why they are there and what is the forecast to be operational in fixes_2_4?

Thanks,
Marcos Douglas

I read the wiki article but I'm a little puzzled.

I can define build modes (Debug/Release) with different compiler/linker options, and this seems to work. It just builds my project with the altered settings, and leaves the packages as is.

However I have to repeat these steps for every project I have or make.

I would however like to have these two nuild modes available in every project.

What I gather from the wiki article is that if I make build macro's the all the options I have in them will be passed to all packages and all packages are re-build with that option as well?

To make clear what I want:
In all projects I have available a Debug and Release mode, these modes are the same for all projects I make/open.
The options I set in these modes do not force installed packages to be re-build with my options (-gl -gh etc).

Is such a thing even possible (and is fo, how)?

Bart

You could create a project template with the two build modes. This is somewhat static. That means when you want to change the -gl into -ghl then you have to change all projects.

To get it more dynamic you can store the options in a package: Create a package, let's say bartssettings.lpk. Define two build macros bartssettings_options and bartssettings_modes. Add two values to bartssettings_modes: release and debug. Add in conditionals:
if bartssettings_modes='release' then

  bartssettings_options:='-O3'

else

  bartssettings_options:='-gh -gl';

Then in the usage / custom options set $(bartssettings_options). Every project that uses this package can now choose the build macro bartssettings_modes to get the options.

Mattias

Very, very good!
What is the forecast to be operational in fixes_2_4, please?

Marcos Douglas

fixes_2_4 is a fpc branch.
That is independent of Lazarus build modes.

Mattias

Very, sorry...
I did mean /branches/fixes_0_9_30

Thanks,
Marcos Douglas

Nice feature. Only take a look at it now

Is it possible to define dependency for a package conditionally?

Say i have a package x that depends of package y for some debug features but, in a release, i don't want the user be forced to download/use package y

Luiz

So, you have a output directory for each package, compiled with no optimizations.
When you want a new release, you set only one directory for all ppu files (project and package's files) and uses the -B argument to compile.

I understood right?

Marcos Douglas

2011/7/14 Mattias Gaertner

I am trying out the approach now.

I create a lib directory where the units would normally go and make it write protected.

Forcing a new lib directory for each package causes dcpcrypt and dcpcrypt_laz to have separate lib folders created for them and cause duplicate unit errors.
Is there some way to work around it? Does Lazarus default to the first one it finds in the units directory?

ZeosDBO switched to using the units in the 'build' subdirectory so I write protected that directory as well.

Indy revealed a problem with .rst files because utilities processing them may hardcoded to write to lib\ directory