Hi,

I like when release my project to compile all components and LCL with special options like change the optimization for example to make the best file execute.
Is it possible and how when i am using LazBuild in command line?

I already have mode "Release" with that options, but not sure it take over LCL sourcecode too.

Zaher Dirkey wrote

I already have mode "Release" with that options, but not sure it take over LCL sourcecode too.

No, that is the really annoying thing about Lazarus Packages. Settings do not resonate up the hierarchy. So if you have settings in your Project, it is only for your project files, and not for any dependant packages.

Mattias once mentioned there is a possibility of having settings resonate up the package hierarchy, but that meant Macros and other trickery - thus modifying all packages that get pulled in by your project.

Lately I find simply not using Lazarus Packages much easier. I setup a project template with all the correct search paths for my most used components (you can do that in fpc.cfg too). Project compiler settings then apply to ALL source code. This is how I roll these days. YMMV

Regards,
- Graeme -

Yes, with macros you can force packages to be recompiled on project changes.

You can also change all (almost all) packages very quickly.

Most packages depend on FCL. So in FCL you can add options to the custom field in the "Usage" section. Anything that uses FCL will look at that "Usage" section

?Hi, again, i failed to do that, any example to do it, for SynEdit package?

?Thanks

I am using last revision of Lazarus, FPC 2.6 on Windows XP SP3

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

1) If you want a single package only, open the package and edit the options like for a project.

2) Do add the same settings as for the IDE (from "configure build IDE") http://imagebin.org/253861
Add $(IDEBuildOptions) to the custom options

Or for the options from the project: $(ProjectOpts)

Check the compiler output ("test" button) for the order it applies.

If one setting has -O1 and the other -O2 then the order matters. The order can not be changed.

Afaik (please verify, not sure) an -O1 does NOT undo a -O2. But a -O-1 does undo a -O2

3) For (almost) all packages.
Check package-graph for dependencies on FCL (includes indirect dependency)

http://imagebin.org/253862

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

?Not worked for me, i Added $(ProjectOpts) to custom options in SynEdit package (same with my packages but i will take SynEdit as example)? What i have
I Have 2 build mode (Debug, Release) i want when use Debug all compiler option passed to SynEdit package and have debug info and so on, When use Release same.

I have tested all adding $(ProjectOpts) or $(IDEBuildOptions) but debug not added to the sources.

Hm, yes, sorry $(ProjectOpts) may not work. Not sure where I picked it up, but I had it as a left over.

If you want to push changed project options, down into the used packages, then that is going to be tricky. (Dependencies normally do not go that way)

IIRC ( I do no longer have my example, but I did have it working once) You can define "IDE Macro" or values, in the project (they should be able to depend on build mode)

In the package, under IDE macros, you add (in the lower field "conditionals"

     if defined(MACRONAME) then
        CustomOptions := ' -O-1 ';

There is a wiki page about that too (sorry havent got the link). It is a big page, and a lot to read.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/8e40893c/attachment-0001.html>

?Is is like
        if defined(RELEASE) then
           CustomOptions := ' -O-1 ';
If yes it will be the "head of the yarn"(proverb)

Martin wrote

if defined(MACRONAME) then CustomOptions := ' -O-1 ';

Zaher Dirkey wrote

?Not worked for me, i Added $(ProjectOpts) to custom options in SynEdit package (same with my packages but i will take SynEdit as example)? What i have I Have 2 build mode (Debug, Release)....

I use lots of build modes too... like I said, the Lazarus Package idea was more problems than anything else. Now I just define all source paths as needed.

And in IDE's like Maximus or MSEide, it makes such configurations dead simple. See the last image of the page below.

http://fpgui.sourceforge.net/screenshots_apps.shtml

By default there are six build modes. For source paths I use macros like ${fpgui}, ${tiopf} etc... Macro values can be toggled by a single click to say which Macro Group you want to use (eg: one group for Windows, one for Linux, etc). Also in Maximus, all build modes have keyboard shortcuts. I normally use mode 'M - Make' for development with debug info, 'B - Build' for releases, and 1-4 for various other things.

Unfortunately the screenshot doesn't use compiler defines in that configuration, but my projects use many. Simply click which build mode they belong - as easy as that.

Regards,
- Graeme -

Zaher Dirkey wrote

Is is like if defined(RELEASE) then CustomOptions := ' -O-1 '; If yes it will be the "head of the yarn"(proverb)

Isnt the above identical to the below?

When I did it, I did have to define the MACRO myself. (in the project, in each buildmode.

I do not know if there are predefined macros

"head of the yarn"(proverb)

I couldn't find any reference to that. Neither www.phrases.org.uk nor urban dictionary have it. Even google doesn't find anything -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/36bd263c/attachment.html>

I guess the original proverb is closer to 'tip of the string', meaning like the 1st lead or clue of a mystery or case.

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/053ce362/attachment-0001.html>

?fpGUI is in my list, but now i like to close my opened projects before looking up to another sources, we have hard time here.? Now there is Maximus i like the design :-)

On Sat, Apr 13, 2013 at 10:30 PM, Graeme Geldenhuys <

I am using last revision of Lazarus, FPC 2.6 on Windows XP SP3

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/6868b041/attachment.html>

patspiper wrote

I guess the original proverb is closer to 'tip of the string', meaning like the 1st lead or clue of a mystery or case.

?Yes true :) but i used "Yarn" instead of string, because string is reserved word :P

Sorry for off topic.

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/1a12f028/attachment.html>

Ok, thanks for the meaning of it. Still not found it on the web.

Is this an American or UK proverb? Or translated from another language? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/b6445da1/attachment.html>

Martin wrote

Is this an American or UK proverb? Or translated from another language?

It is from my Arabic ?language, used when we catch the head/tip of the string and start pull it to discover the end of it, it is mean we started(the beginning of) resolving our problem.

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/9deae8ce/attachment.html>

Hehe. :-)
http://article.gmane.org/gmane.comp.ide.mseide.user/18779 ;-)

If one likes to see the original:
http://mseide-msegui.sourceforge.net/pics/optionsmake.png http://mseide-msegui.sourceforge.net/pics/optionsdirectories.png http://mseide-msegui.sourceforge.net/pics/optionsmacros.png

Martin

?What is B,M,1,2,..6, is it Build Modes also??

Zaher Dirkey wrote

?What is B,M,1,2,..6, is it Build Modes also??

The menu items 'Project'-'Make','Build','Make 1','Make 2','Make 3','Make 4'. http://mseide-msegui.sourceforge.net/pics/projectmenu.png

Martin

Martin Schreiber wrote

> Hehe. :-) http://article.gmane.org/gmane.comp.ide.mseide.user/18779 ;-)

:-) [how do you guys find such old email of mine]

Anyway, that was probably before I knew about using configurable Macros in paths - a MSEide help file would have gone a long way. Maximus IDE (experimental project) does similar to MSEide, but not exactly the same. For example, I split session information and project settings (separate files), I also allow configurable (from within the IDE) Global and per Project macros. These were small things that annoyed me of MSEide. But overall, I think the Compiler Options flexibility you created in MSEide is awesome! :)

Regards,
- Graeme -

Zaher Dirkey wrote

?What is B,M,1,2,..6, is it Build Modes also??

Yes. 6 build modes are available for use. Maximus allows more, but starts with 6, and also has keyboard shortcuts for each build mode. So building using a different build mode is simply a click away, or via a keyboard shortcut. Defining each build mode, is simply a matter of ticking a box saying which compiler setting applies to which build mode column.

All in one screen, and personally I think much simpler than what Lazarus IDE does.

Regards,
- Graeme -

I would be happy to have all information in one screen too. But IMO it is not that easy. MSEIDE uses a small font and its own dense theme. Lazarus should work with the users theme.

And Lazarus needs settings for packages. For example it must be possible to apply some settings only to the project and packages A,B,C, or to all except packages X,Y.
And such settings needs to be stored either globally, in the lpi or the lps.

So Lazarus needs to handle more information on less space. MSEIDE uses single character abbreviations to save space. That's a bit confusing, but it is ok, because it is the only element. Lazarus needs a grid, where build modes, storage and scope are handled, so abbreviations would be quickly misunderstood.

Maybe you have some ideas how to put that into a grid that is easy to understand?

Mattias

Mattias Gaertner wrote

Maybe you have some ideas how to put that into a grid that is easy to understand?

I'll take another look at the Build Mode settings is Lazarus and report ideas I come up with.

The current Build Mode settings is Lazarus IDE is very confusing though
- even though there was good intentions not to make it confusing. eg: I could type in the name of a non-existing marco (grid in Build Modes screen), and give it a value. But because that marco wasn't defined in another area of the Project Settings (Build macros screen), it didn't work. So why didn't Lazarus IDE report the problem, or why was I allowed to type in a non-existing macro name, or why didn't it automatically define that macro.

Regards,
- Graeme -

You can define any macro you like. The name must follow the normal pascal identifier rules.

Mattias

Mattias Gaertner wrote

You can define any macro you like. The name must follow the normal pascal identifier rules.

Yes I understand that, but you must first define the macro (somewhere else), before using them in the Build Modes screen. Lazarus IDE didn't prevent me from trying to use a macro in the Build Modes screen (with a legal pascal identifier rules name) that doesn't yet exist.

[hope I'm explaining this clearly]

Regards,
- Graeme -

No, you can define any macro you like in the project options. And then you can use the macro in the compiler options of project and packages. For example in search paths and custom options.

Maybe you are confusing it with the macros from conditionals? Conditionals have to define the macros they export.

Mattias

Our problem here
I like to define a Many named Build profiles(Modes), for example, i want to build my project with special defines to make project for "Pascal" or "PHP" or "ALL"
and for WINCE Wegetset etc. many of them.
But we need debugging it when compile it in IDE, not the project only also many components have it in other packages.
And we need to release it without debug info that mean need another Dimension for Build Modes/Profiles, at least DEBUG and RELEASE for all Build Modes/Profiles
Also Lazarus and its Components must have 2 of dir one for Debug other for Release depend what we choose of current mode, that prevent from rebuild all of packages every time changing from DEBUG to Release and vise versa.

(Oh My English)

Zaher Dirkey wrote

Our problem here I like to define a Many named Build profiles(Modes), for example, i want to build my project with special defines to make project for "Pascal" or "PHP" or "ALL".... snip....

Yes, I fully understand what you want to do. And like you I simply couldn't figure out how to accomplish that with Lazarus IDE. With MSEgui, and even with Maximus, it was really simple to accomplish what I (and apparently you) wanted.

Regards,
- Graeme -

To get more variations in output directories you have to alter the packages (lpk).
To add options to packages as well.

Eventually such additions will be configurable in the IDE.

Mattias

On Mon, Apr 15, 2013 at 9:21 PM, Mattias Gaertner <

?Directories to put precompiled units *.o? of Packages, when compile the project it take the right .o Depend Release or Debug, so it is IDE/Envirement mechanism, Delphi do that for VCL, and Visual Stutio.

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130415/436a8d2e/attachment.html>

Some people want Debug/Release, some Debug/Profiling/Release, some Experimental/Normal, some Debug/Release x WidgetSet and so forth. IMO Lazarus should provide such flexibility.

Mattias

Can the Lazarus core packages have a macro in their unit output directory in order to "inherit" the correct path upon rebuilding the project or the IDE itself?
ex for LCL:
../units/$(TargetCPU)-$(TargetOS)/$(LCLWidgetType)/$(BuildModeFolder) LCL has $(IDEBuildOptions) in its customs options. I am not sure if it inherits macros as well.
Is there an equivalent $(ProjectBuildOptions)?

The above would be the 1st step towards such a solution.

Stephano

And who changes all the other third party packages?

And some developers may prefer this:
/Developer/$(BuildMode)/$(PkgName)

I think an override would be more flexible. It should also a contain a scope option. To handle some packages differently.

Mattias

On Tue, Apr 16, 2013 at 10:38 AM, Mattias Gaertner <

wrote: /Developer/$(BuildMode)/$(PkgName)

/Developer/$(BuildMode)/$(PkgName)
??$(BuildMode) BuildMode here is user defined. many names come for each project, need new name variable DEBUG_OR_RELEASE (example name) /Developer//$(PkgName)/$(DEBUG_OR_RELEASE)
DEBUG_OR_RELEASE can take DEBUG value or RELEASE. (i know DEBUG_OR_RELEASE is bad name)

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

Yes.
Although it might be a good idea to add a macro for the name of the active build mode and I guess BuildMode is a good name for that.

[...]

Mattias

On Tue, Apr 16, 2013 at 11:18 AM, Mattias Gaertner <

?Good and not :P?

?Here, it is not good to pass it to the packages include LCL and maybe (FCL even the FPC pascal one) when compile the project, because it it is variant name.

My need the build take Debug dirs (*.o units) if we define Debug or Release dirs when define Release, let name it BuildState (i am not good in naming)

We need this also even compile FPC projects, so ?(non LCL), i think FPC developer can take a look to this thread.

I added that.

Can you explain this?

My need the build take Debug dirs (*.o units) if we define Debug or Release dirs when define Release, let name it BuildState (i am not good in naming)

I got the feeling, you are still at only two modes.

We need this also even compile FPC projects, so ?(non LCL), i think FPC developer can take a look to this thread.

The compiler has nothing to do with build modes.

Mattias

On Tue, Apr 16, 2013 at 2:30 PM, Mattias Gaertner <

wrote: I got the feeling, you are still at only two modes.

I have a lot of build modes?, but i missed founded in Delphi 4 and above When i compile project to debug it, i can (In Delphi) debug inside the sources of VCL or more deep than VCL, Delphi will choose DCUs that in Debug dir

C:\Program Files\CodeGear\RAD Studio\5.0\lib\Debug

But when we not debugging it, it will choose DCUs in Release dirs or in fact in the parent it

C:\Program Files\CodeGear\RAD Studio\5.0\lib

?We need that at least in Lazarus, and it will be good in FPC too.

?My problem: i debug my project inside my packages(My Packages) and some LCL or Components, so i need to rebuild all packages with Debug info no optimize.
When i need to make realase my project i must rebuild all of them again with no debug info and some optimize, i build the project, it is so hard switching.

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

You can create various config files.
Depending on what 'mode' you want, you can simply specify a different config file when compiling.

Michael.

On Tue, Apr 16, 2013 at 2:52 PM, Michael Van Canneyt <

wrote: You can create various config files. Depending on what 'mode' you want, you can simply specify a different config file when compiling

?In Packages in LCL and Lazarus Components and My Packages??

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

1st, to clarify, $(BuildModeFolder) is a macro derived from the actual build mode name (or some user defined value in each build mode).

In this case, 3rd party packages would have to be handled either by the package maintainer or by the user.

An override would be super and very flexible! It would handle all packages.

However, maybe a distinction (separate settings) should be done for the user project/packages, Lazarus core packages (LCL, SynEdit, ...), and FPC packages (FCL). The reason is that a user may need to debug his code only, his code + Lazarus' code, or his code + Lazarus' code + FPC code. Stepping over FCL code is almost always the case for regular users and probably Lazarus devs.

IIRC, Delphi has Debug and Release dcu's for the VCL.

Stephano

or use IFDEF's and macros in fpc.cfg

Stephano

That's what I mean with scope.

Mattias