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

[n7800]

This is also related to the following feature request:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/29511

And I think there will be many more parameters that will return some kind of project information (LPI). This will allow you to create more flexible build scripts.

It might not be a good idea to have lazbuild do this. However, who else? It still does this on every build. Why create and maintain a separate utility? Due to various errors (different version or working directory), it may return different information than lazbuild. Let lazbuild do it.

[n7800]

I think the "--dry-run" parameter is unnecessary. It makes no sense to return a list of macros after building; usually they are needed before, or instead of, building. Moreover, during building, the output will contain compilation results, which will be difficult to distinguish from the returned text with macros.

In addition, with the second parameter it will be too long:

Code: Bash  [Select][+][-]

1. lazbuild project1.lpi --expand-macros="text with macros"
2. # or
3. lazbuild project1.lpi --action=expand-macros --text="text with macros"

Along with the name of the utility, project and the text itself, you need to write "--action=expand-macros --text=". This is very long. Look at the FPC arguments - most of them are only one or two letters long!

Martin, I don't understand your concerns. Even if the user waits for the build when specifying this parameter, nothing bad will happen. He will see the text in the output (with macros expanded) and understand that the build did not occur.

In addition, the user will only learn about this command from the help, and there it will be clearly written: "expand macros in the text instead of building."

By the way, lazbuild already has 4 commands that cancel the build:

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

1. --help
2. --version
3. --create-makefile
4. --add-package-link

So introducing something like "--dry-run" will only break the already existing format.

Look also at the arguments to "gcc" or "msbuild" - there is no division between "actions" and "arguments" anywhere. For example, the "-c", "-S" and "-E" arguments to the "gcc" compiler override the build (partially).

Any user must understand what the command he enters does.

[n7800]

As for the name of the parameter itself, I don’t think it’s necessary to indicate the word "macro" in the name. For example, in the Windows system registry there are types of keys:

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

1. REG_SZ        // "constant" string
2. REG_EXPAND_SZ // string with environment variables (%APPDATA%)

Macros are essentially Lazarus "environment variables".

So, I personally suggest the "--get" option without additional arguments:

Code: Bash  [Select][+][-]

1. lazbuild project1.lpi --get-expand-text="text with macros"
2. lazbuild project1.lpi --get-build-modes
3. lazbuild project1.lpi --get-exe-path

I think there is no need to explain what these example commands do. For example, the last command allows you to get the path of the executable file so that you can run it from the same script.

[Martin_fr]

I have to remind myself of all that had been discussed (it's been a while...), but IIRC the idea was to introduce *ONE* new param, which could take an action (not yet gone so far as to think if it ought to be verb or noun...).

lazbuild currently as default does "build". Anything else must
- clearly be marked as **alternate** action
- i.e. not only express what it should do, but also express that it should **not** build.

As for the replacing of macros (or anything that acts on an arbitrary input text: It would be nice to include an option to read stdin (even if not yet implemented).

That would mean, that the action is best specified separately from the object (the text).

[JuhaManninen]

So, I personally suggest the "--get" option without additional arguments:

Code: Bash  [Select][+][-]

1. lazbuild project1.lpi --get-expand-text="text with macros"
2. lazbuild project1.lpi --get-build-modes
3. lazbuild project1.lpi --get-exe-path

+1
I like that. It is simple and intuitive and covers https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/29511.
The syntax from Martin turned unnecessarily complex.

[Martin_fr]

My understanding of the original "macro replacement" was that this may have been wanted for usage in a script.

I.e., the script would have some data that contains macros, and needs the resolved text.

IMHO, it is merely a matter of time, until such data contains quotes (and possible line-breaks). And once it does, passing it as argument requires extra work. (afaik..., maybe not?).

So something like (whatever the actual syntax would be...)
   MYVAR=($ cat mydata | lazbuild __arg_to_resolve__ )
might be helpful

or
   MYNEWVAR=($ lazbuild __arg_to_resolve__  --  $MYVAR )
where all the text after the -- is treated as input