Hello,

Currently, the options specified in 'Run - Parameters' are stored in the project.lpi file.

I have always found this a strange choice.
What is the rationale for this decision ?

Logically, I would I think these parameters belong in the .lps file ? For example: a program that takes a filename. On my home PC, the file is in one location. At work, it is in another location.

Since these parameters are in the lpi file, they also gets checked in into git or svn, when in fact nothing has necessarily changed in my project if I just did a debug session with different parameters... Thus causing many false 'modified' notifications, or often worse, conflicts when 2 different command-lines exist.

Some programs accept a --username or --password option. I had several cases where my username/password were saved in a .lpi file and checked in, thus exposing my credentials to collegues...

So, would it be an option to have the run parameters saved in the .lps file? This would avoid many of the pitfalls.

Michael.

Some projects need the same run parameters on all machines. For example instantfpc projects can't run with the default run params.

Logically, I would I think these parameters belong in the .lps file ?

I agree, there should be an option. Or even better would be a list of run modes.

Some developers using build modes suggested to have different run parameters per build mode. So it would be nice if the list and build modes can be connected. For example when switching the build mode, the IDE automatically switches the run mode too.

Mattias

For example, testsuites. I keep setting the --suite=TestA.MethodXYZ. My collegue sets it to --suite=TestB.MethodC.
It gives me conflicts every time I update from SVN.

And in this case you almost never use the same command-line twice.

> Logically, I would I think these parameters belong in the .lps file ? I agree, there should be an option. Or even better would be a list of run modes.

Don't get overenthousiastic. Keep it simple :)

The trouble with a list is that you must maintain it, just as the build modes. I don't want that.

So if you do decide to introduce it, please keep it optional, as the build modes.

Not to say there is already a list, namely the history mechanism.

Well. If you can give a global option

Save "run parameter" settings in
[*] .lpi file
[ ] .lps file
[ ] run modes
[ ] build mode

I will be satisfied.
You could use the ones in .lpi as a fallback, in case they are not set in the .lps

Michael.

I think having a list for run modes (i assume you mean the settings you specify in the Run -> Run Parameters dialog box) that you can select from a popup menu near the "play" button and have different run modes apply, like you can select the build mode from the "gear" button, is a good idea. Being able to switch configuration files and working directories from inside Lazarus for some of the tools i work with would be very nice.

The only thing i disagree with is to have them per build mode since chances are you'd need them with different build modes (e.g. debug, release, profile, etc would have the same run modes) and even if you could copy them, it would still be an annoyance to make sure all are available.

Instead i'd say to have a table with a column per build mode and a row per run mode, have checkboxes for those that will apply and those checkboxes would be enabled by default.

Alternatively just use a global list that is the same across all build modes, but then you may have run modes that do not apply in all build modes and have them take up space (e.g. if one of your run modes causes a program to load a 32bit DLL and you are in a build mode that explicitly targets a 64bit OS this run mode wouldn't apply - of course one case wouldn't matter much, but the next thing i imagine after such a feature is available is being able to generate run modes automatically though a script :-P).

Kostas

On Sat, Feb 11, 2017 at 1:15 PM, Michael Van Canneyt via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170211/3dc7bff6/attachment-0002.html>

If you want a list, I would simply allow to make a list as you suggest, and for each build mode you can simply specify which item in the list is used as default when pressing run. Being able to specify multiple run modes per build mode seems way overkill to me.

I don't want to end up with Eclipse, where you need a Phd in Eclipse to be able to do even simple tasks in the IDE...

Michael.

The problem of not associating build modes with run modes is that not all run modes will apply to all build modes. Note that i don't think run modes should be *part* of build modes, but only an association between build modes and run modes. Basically, what you say about a default run mode per build mode, i say to make it a list of what is *not* (from a UI perspective you'll see them as what is part, but only store what is not so that when you add a new run mode it is available to all build modes without the user needing to go at each one and enable it).

On Sat, Feb 11, 2017 at 3:31 PM, Michael Van Canneyt via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170211/06f2767d/attachment.html>

Michael Van Canneyt wrote

Logically, I would I think these parameters belong in the .lps file ?

I fully agree, they should be stored in the .lps - I don't care about lists or build modes and all that jazz. The accidental committing of user credentials into a code repository has bitten me a few times. The same goes for commit conflicts after getting a repository update because other developers tested with different parameters. All very annoying.

Regards,
Graeme

+1