Slight improvement for lazbuild

[zamtmn]

>>Option 1)
>>lazbuild --dry-run   --show-macro-values=TargetCPU,TargeOS
yes, it's probably logical, but I don't see any practical application for this

>>Option 2)
>>lazbuild --replace-macros-in-text    < input.txt
Also a problem. We don't make a parser to run files through it... We just need to get a few values from the Lazarus settings and lpi file

I vote for

Code: Pascal  [Select][+][-]

1. lazbuild myproject.lpi --what-you-want-option-name=text$(macro1)text$(macroN)text

it is simple and understandable both for implementation and for use IMHO

[Martin_fr]

expand, replace, substitute are all ok within "--....-in-text". 
"expand" may indeed have the advantage of not (or less) implicating that the original (text) is replaced.

But just had another idea.

Since lazbuild will likely grow... And then we need a clear and consistent interface.
That means it will be important to distinguish between parameters that
- are options to the build (or other selected action: create-makefile, translate)
- are an action (do something else, other than build)

So maybe we should do (instead of --action it could be --tool

Code: Text  [Select][+][-]

1. lazbuild --action=build  ## default, not needed to be specified
2. lazbuild --action=create-makefile   ## For compatibility we keep --create-makefile as shorthand
3. lazbuild --action=replace-macros-in-text  --text="...."

Using the --action= we may come up with some shorter "action name": --action=expand-macros

"expand-macros" is not as verbose, and could have other meanings. But the context now clarifies it is its own action, it is *not* build. So I think its ok.

[Martin_fr]

>>Option 2)
>>lazbuild --replace-macros-in-text    < input.txt
Also a problem. We don't make a parser to run files through it... We just need to get a few values from the Lazarus settings and lpi file

I vote for

Code: Pascal  [Select][+][-]

1. lazbuild myproject.lpi --what-you-want-option-name=text$(macro1)text$(macroN)text

it is simple and understandable both for implementation and for use IMHO

I edited my post / dropped the stdin requirement.

I currently stick to the 2 argument version
- the action
- the data

Mixing the action and data into a single param, is IMHO not good at all.

But lets wait for some feedback, which of the options....

Code: Text  [Select][+][-]

1. lazbuild --replace-macros-in-text  --input-text="foo($TargetOS)"
2. lazbuild --action=replace-macros-in-text  --text="foo($TargetOS)"
3. lazbuild --action=expand-macros  --text="foo($TargetOS)"

[zamtmn]

it seems that no one except me is interested in this problem))

[MarkMLl]

I'm interested, if it allowed a Makefile to be produced. But not ATM able to put time into it, and hesitant to intrude on the developers' complex build process.

MarkMLl

[Martin_fr]

it seems that no one except me is interested in this problem))

It wasn't entirely rejected. But there are very restrictive rules to how to pass params.

I need to go back though my notes, before I can comment, and at the moment I am running out of time.....
Ping me in Feb, please.

[Martin_fr]

Ok, I went back through my mail (I had an exchange with other members of the team).

As I indicated here, it is important that the command line makes it clear that there will be no build.  Putting "only" into the parameter does not sufficiently do that.

The feedback I had was clearly favouring

Code: Text  [Select][+][-]

1. lazbuild --action=expand-macros  --text="foo($TargetOS)"

I can also live without the --text, but then the input is not allowed to start with a dash -.
E.g

Code: Text  [Select][+][-]

1. lazbuild --action=expand-macros  foo($TargetOS)

But NOT allowed

Code: Text  [Select][+][-]

1. lazbuild --action=expand-macros  -foo($TargetOS)
2. lazbuild --action=expand-macros  bar -foo($TargetOS)
3. lazbuild --action=expand-macros  "-foo($TargetOS)"    
4.  

E.g. after the last parameter, the remaining text is to be translated.
But since there could in future more parameters, the text can not start with a dash -, nor can any space separated part start with a dash unless quoted (in quotes the first char can not be a dash).

That is a good deal more complicated to parse...

So if you change the merge request to match the above, then I will apply it.

Mind, Next week, I will be away for a few days.

[Martin_fr]

Actually, I was to fast on the alternative, leaving out the --text.

Can't take the rest of the command line, because the project needs to be specified too.

So it has to be

Code: Pascal  [Select][+][-]

1.     lazbuild --action=expand-macros  --text="foo($TargetOS)"  project.lpi

[zamtmn]

OK. I'm a little busy right now, later I'll try to do as you said