Hi,
is there an easy way to switch between different compile configurations? In C++ projects you usually have debug/release configurations, and what I need
in Lazarus, are three configurations: debug (range/overflow check), release linux (smart linked, optimized),
release windows (smart linked, optimized, cross compiled)...

Benito

2010/9/25 Benito van der Zander :

Not really easy. The easiest way is to save your compiler options and reload them when you want to switch.

Vincent

Benito van der Zander wrote

in Lazarus, are three configurations: debug (range/overflow check), release linux (smart linked, optimized), release windows (smart linked, optimized, cross compiled)...

Many have asked this, but it is clearly not a high priority for the Lazarus developers. There are a few options though.

Option 1) Project Options > Compiler Options > Other > "Use additional compiler config file"
You can create various config files with different compiler parameters (remember one
parameter per line in the config file).
I have two such files: mm_debug.cfg and mm_release.cfg

Option 2) Switch to MSEide instead. There it has 6 or so different build modes. MSEide makes this really easy to setup, and very easy to select between build modes. Simply choose one of the top level menu item (build modes) in the IDE's main form (first 6 items under the Project menu).

Not work if you Debug or "Find Declairation", Lazarus not load the Pathes from the config file.

2010/9/26 Zaher Dirkey :

Not work if you Debug or "Find Declairation", Lazarus not load the Pathes from the config file.

I don't use those config files for setting paths, but for other compiler parameters like heaptrace, line info, optimization level, cpu choice etc... for all that it works fine.

But maybe you should file a bug report on the paths issue.

For the windows build I solve this problem by having an external tool configured that will simply call

$(SaveAll)$(Home)/.wine/drive_c/lazarus/lazbuild.exe

with the current project in the current project directory to quickly make a windows build of any project with just two mouse clicks. Unfortunately it is not possible to pass additional parameters to lazbuild that would allow to override the compiler flags or specify an additional config file.

Maybe it would be a good idea to file this as a feature request against lazbuild because I think
(a) it should be easy to implement without affecting or interfering with any existing functionality
(b) would allow for some really useful general purpose command lines for lazbuild.

Graeme Geldenhuys wrote

Many have asked this, but it is clearly not a high priority for the Lazarus developers.

It is a high priority. Just because it isn't implemented yet doesn't necessarely mean it isn't.

Felipe Monteiro de Carvalho wrote

It is a high priority. Just because it isn't implemented yet doesn't necessarely mean it isn't.

I simply meant the request for that feature has been around for years, but many other new features (that arrived later) have been implement first. Lazarus project has no clear roadmap, it's just random features being thrown into the mix to make the next release.

Graeme Geldenhuys wrote

I simply meant the request for that feature has been around for years,

A feature request without patch is just wishful thinking.

Might I ask what prevented you from sending a patch?

but many other new features (that arrived later) have been implement first. Lazarus project has no clear roadmap, it's just random features being thrown into the mix to make the next release.

All added features are top priority. Maybe not your top priority, but surely the top priority of someone else who coded (or funded) the implementation.

Build modes do are a top priority, although they will still probably take a long time to get fully implemented (my guess = 1 year). Of course I would be extremely happy if people start sending patches which are in line with Mattias's plans for this feature and which accelerate the completion time.

Felipe Monteiro de Carvalho wrote

A feature request without patch is just wishful thinking.

I know that! Hence the reason I have contributing many patches before. I know the whole "that is the way open source software works" story. Unfortunately that ideal world doesn't always work either - patches can be supplied with a feature request, but that is NO guarantee that they will be accepted into the Lazarus project. My last two patches are a case in point (a bug report + patch). So far they are just collecting dust in Mantis (one goes as far back as April). Mantis is full of patches waiting to be applied.

Might I ask what prevented you from sending a patch?

Time, and the fact that it will touch quite a few deep knowledge features of the IDE. With experience I have noticed that such patches are really accepted (outside the ring of the core developers of course).

All added features are top priority. Maybe not your top priority, but surely the top priority of someone else who coded (or funded) the implementation.

Well, Mantis currently has many patches just sitting there... so that doesn't seem very high priority to me. Also marking a feature or patch as target 1.0, 1.2 or post 1.2 is pretty much a slap in the face. Considering Lazarus has been around for 10 years (I think), and still is no closer to a "stable" or 1.0 release. So a post 1.2 target will obviously not happen in my lifetime.

course I would be extremely happy if people start sending patches which are in line with Mattias's plans for this feature and which accelerate the completion time.

Well, there is no roadmap for Lazarus, so I can only take a wild guess at what Mattias's plans are. Without publishing clear goals/targets/plans for what Lazarus wants to achieve for every release - we (outside the core developer ring) are stuck in the dark. This makes it rather hard to contribute towards a release goal too, don't you think.

About the patches, the whole process is:

1> All incoming patches should be sent to the bug tracker. There they will be targeted to the next release, 0.9.30 never later then that 2> If the patch needs improvement, then it will be said and it looses this target unless a new patch is provided.

There are no exception to these rules. If some patch followed a different route, please provide the bug tracker ID number for it. If it was sent by some other mean then the bug tracker, then I strongly recommend using the bug tracker instead.

Also marking a feature or patch as target 1.0, 1.2 or post 1.2 is pretty much a slap in the face.

About features: I don't agree that marking a feature without contributors to a distant future is a slap in the face.

About patches: This doesn't exist. As explained above they are all targeted to the next release.

Considering Lazarus has been around for 10 years (I think), and still is no closer to a "stable" or 1.0 release. Well, there is no roadmap for Lazarus

http://wiki.lazarus.freepascal.org/Lazarus_Development_Process#What_we_are_planing_to_do http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_todo (not very updated at the moment, but it seams that even your tasks for this release need update)
http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_release_notes (quite well updated)

This makes it rather hard to contribute towards a release goal too, don't you think.

One can just ask. I think that all features which were planned for 0.9.30 were already done. The only things left are:

1> Wait for FPC 2.4.2
2> Fix all 41 bugs assigned for 0.9.30 (including review and apply patches)

Personally I don't have anything assigned for 0.9.30

Other stuff may get fixed and added, but they are more of personal todo lists then Lazarus todo lists.

About contributing towards the release goal, the best method would be by sending patches to fix the issues assigned for 0.9.30

Felipe Monteiro de Carvalho wrote

2> If the patch needs improvement, then it will be said and it looses this target unless a new patch is provided.

I know you distinguished between feature and patch to cover yourself with how the process works. So the feature aspect is still left unknown. Either way, lets take one example, where I think I did everything I could, but got nowhere. I implemented a feature (global file filters config screen), got feedback, made changes, submitted another patch, got feedback, discussed my reasons for implementation.... then...nothing further is said or done. Feature and patches just gaining dust - and probably doesn't even apply to the latest code anymore.

http://mantis.freepascal.org/view.php?id=15679

Similar thing happened to other patches too...

http://wiki.lazarus.freepascal.org/Lazarus_Development_Process#What_we_are_planing_to_do

Telling us what is planned for 1.0 or 1.2 means nothing. As far as I'm concerned, those versions will never happen. GTK1 was a planned for 1.0...Lazarus releases took so long GTK2 was implemented...Lazarus releases took so long GTK2 became the default.... Lazarus releases took so long, now GTK1 is marked as deprecated even before 1.0 was reached.

http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_todo (not very

Now this is the information I'm talking about, but it is so vague and outdated, it also means nothing. No target release date or nothing, so no real goals to strive for. Maybe the core developers don't know about this page, or there is simply no coordination between core developers. Everybody developing in there own little bubble doesn't do the project any good. Even looking at previous release "todo" wiki pages, there are still many items not completed, yet releases were made. So these todo pages seems more like subtle hints or suggestions, than a clear plan or roadmap.

As for the release notes wiki page, that is things that have already been done, not things that was planned for 0.9.30.

One can just ask. I think that all features which were planned for 0.9.30 were already done. The only things left are:

It should be published, not only given on request. But now you answered by questions anyway, nobody has a clue what's going on. I consider you one of the core team members, so expected you to know what was the goals of the next release, yet you don't know or are uncertain regarding what features or bugfixes were supposed to make it in 0.9.30.

1> Wait for FPC 2.4.2

Why? Lazarus is an independent project from FPC. Surely if the 0.9.30 release is based off the fpc "stable" fixes branch that should be fine. Do you guys time Lazarus releases based on GDB releases too? After all, GDB is just as important as FPC is to Lazarus.

Anyway, I'll discontinue this discussion because I think we have all been down this road before, and we know the road leads nowhere. If you want to continue, email me in private.

Well... Lazarus depends more on FPC than on GDB...

But to give you one reason for this (I hope that I remember this correctly): WinCE resource support is broken in 2.4.0 and thus we have no stable compile release with resource support for that platform.

Regards,
Sven