Slight improvement for lazbuild

[zamtmn]

I came across the fact that when compiling an application using makefile, it is difficult to find out some parameters, for example, the bit depth of the compiler. I think it would be right to get it from lazbuild.
Therefore, a small patch https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/129 has appeared that allows you to get some values from the lpi file using lazbuild.
usage example:

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

1. lazbuild zcad.lpi --substitute-macros=$(TargetCPU)-$(TargetOS)

print

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

1. x86_64-win64

[Martin_fr]

I find the name misleading. "Substitute" suggests that something existing is replaced, and so my first thought would be maybe the lpi file is rewritten, with the macro replaced by the actual value.
It took me a while to see, that the parameter actually takes any random bit of text, and replaces macros in it. (so yes "substitute" but this is only a subordinate functionality)

Anyway, IMHO the main function of this is to display the result (on the console). So IMHO, it the param should start with "show" (or maybe "print").

I assume there is a reason why it is not just taking a single macro (or a list of macros), and display each value?
But instead takes any random text, in which it identifies and replaces macros?

Maybe

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

1. --show-evaluated=

The name is not ideal (but any good name that I can think of, would be way to long).
It would be easier if it would just take one macro or a list. (which also would mean, no need for the "$()")

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

1. --show-macro-value=TargetCPU,TargeOS

It also seems as if that param mixes 2 "actions"

1) It prints the value
2) It prevents the actual build

IMHO (but that is subjective) that is also wrong. I may want the values printed, but also have the build happen.
IMHO if the build should not happen there should be a 2nd option "--skip-build"

[Bart]

I agree with Martin.
This:
--show-macro-value=TargetCPU,TargeOS
may be a usefull addition (maybe also a shorthan --smv, like we hve --pcp as alias for --primary-config-path).

Bart

[zamtmn]

Yes, the name is bad, I do not know English and do not know how to give the right names))

I agree to fix it properly (maybe --only-show-macro-value?). But I don 't agree about proposed behavior.

1)This lazbuild call is only for getting information, compilation should not occur in it
2)TargetCPU,Targetos - this syntax complex and requires further combination of these values. The values themselves are usually unnecessary, some combination of them is needed. $(TargetCPU)-$(TargetOS) this immediately gives you what you need and essentially just repeats the syntax from the project settings, with all the same macros.

[Martin_fr]

Yes, the name is bad, I do not know English and do not know how to give the right names))

I agree to fix it properly (maybe --only-show-macro-value?). But I don 't agree about proposed behavior.

I would also suggests that the output would then look like (either "=" or ": " (space after colon))

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

1. --show-macro-value=TargetCPU,TargeOS
2. TargetCPU=x86-64
3. TargetOS=Win64
4.  

(One per line).

Though I do not know if that works for what you want to do with the output. If you have a script, it would need to parse this.

1)This lazbuild call is only for getting information, compilation should not occur in it
2)TargetCPU,Targetos - this syntax complex and requires further combination of these values. The values themselves are usually unnecessary, some combination of them is needed. $(TargetCPU)-$(TargetOS) this immediately gives you what you need and essentially just repeats the syntax from the project settings, with all the same macros.

As, I said, this is just my opinion (i.e., not a blocker for the issue). Let's see what others think.

I just checked, we also already have

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

1. --create-makefile
2.                       Instead of compile package create a simple Makefile.

So it would be ok, to have "--show-macro-value=" skip the build. The help item would have to say "Instead of compile"

[MarkMLl]

I just checked, we also already have

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

1. --create-makefile
2.                       Instead of compile package create a simple Makefile.

So it would be ok, to have "--show-macro-value=" skip the build. The help item would have to say "Instead of compile"

I'm glad you mentioned that. At present (2.2.4) it does nothing if building a main project: is that easily fixable?

If putting something on e.g. Github, particularly if it can be compiled as a console program without requiring the LCL etc., I prefer to put a makefile with it to conform to industry expectations. By now I've tweaked that to include e.g. zipping for publication and testing the .zip's completeness, but it would still be useful to have the skeleton of a makefile automatically generated.

MarkMLl

[Martin_fr]

I just checked, we also already have

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

1. --create-makefile
2.                       Instead of compile package create a simple Makefile.

So it would be ok, to have "--show-macro-value=" skip the build. The help item would have to say "Instead of compile"

I'm glad you mentioned that. At present (2.2.4) it does nothing if building a main project: is that easily fixable?

No idea. I haven't ever looked at that part. Only found it in the help ("fixable" => "extendable". It's not broken, it says "...a package")

[MarkMLl]

No idea. I haven't ever looked at that part. Only found it in the help ("fixable" => "extendable". It's not broken, it says "...a package")

I didn't /quite/ say it was broken (and certainly didn't intend to :-)

I looked after somebody raised it in an earlier thread... my problem is that I'm not really a package user so don't have a good understanding of what it actually does and how that could be extrapolated to doing the same for a full program.

MarkMLl

[zamtmn]

Change parameter name to only-show-macro-value and add error messages for invalid params combinations

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

1. >lazbuild.exe zcad.lpi --create-makefile --only-show-macro-value=$(TargetCPU)-$(TargetOS)-$(LCLWidgetType)
2. Error: invalid parameter: create-makefile and only-show-macro-value= parameter

[JuhaManninen]

One choice is to have another utility program for showing macro values of a project or package, named as "showmacros" or something.
Lazbuild is for building as the name hints. Generating Makefiles ìs part of building process, too, and thus logical.
Showing macro values however is not building.

[zamtmn]

This program will mostly copy lazbuild. We need to split lazbuild well in order to reuse the code.

Also, the advantage of including this functionality in lazbuild will be that it will take into account all redefinitions made on the command line (--primary-config-path, --operating-system, --widgetset=<widgetset> etc...) and it will show macros that will be used during compilation with these settings

[JuhaManninen]

Also, the advantage of including this functionality in lazbuild will be that it will take into account all redefinitions made on the command line (--primary-config-path, --operating-system, --widgetset=<widgetset> etc...) and it will show macros that will be used during compilation with these settings

OK, that is a good point also.

About splitting LazBuild:
It uses units which are also used by the IDE. Many of them depend on LCL while they should not. For example units dealing with a project and with a package should not depend on LCL.
The underlying code should be split into packages and dependencies should be reduced. It is an unbelievably hard task.

[Martin_fr]

I think using lazbuild for this is ok.
It really rather is a dry run.

Still fuzzy on the exact interface...

I don't like the "-only" in the option. (at the very least not as first token, but in general not at all)

Also it seems zamtmn wants to have more than just the macro values.

Because the simplest option to print the macro values would be:

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

1. lazbuild --dry-run   --show-macro-value=TargetCPU,TargeOS
2.     TargetCPU=x86-64
3.     TargetOS=Win64

Or just show all macros:

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

1. lazbuild --dry-run   --show-macro-values
2.     TargetCPU=x86-64
3.     TargetOS=Win64
4.     ....

But the proposed solution is not "show macro values", it is "parse random text and show result with macros replaced".
I am not sure, if that is the better option (I can see how it might be used, if you have a text (e.g., a path) with macros).

The question is, if just because we already have that parser in lazbuild, then should lazbuild be call-able as such a parser? Not sure. It's one step further from it's purpose. Yet it's convenient.

In any case (and maybe I did not make it clear enough before) => if it should act as a parser (rather that just (verbose/debug) printing the macro values) then the option needs yet a different name.
Something like (and that is not the final answer, probably needs a better idea):

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

1. lazbuild --replace-macros-in-text="foo($TargetOS)"  ## Strongly disliking this version / Objecting to it
2. lazbuild --replace-macros-in-text    < input.txt
3. echo "foo($TargetOS) | lazbuild --replace-macros-in-text
4. "

The point here is that lazbuild now takes an extra input: the text-to-be-translated.

The first version (supply text as argument) is misleading. It does not bring forth the fact that "--replace-macros-in-text" is an alternative action (instead of "build").
IMHO, if inlined it calls for --dry-run or without dry run should do a build too.
Where as the 2 option that have just "--replace-macros-in-text" (with no text as part of it) read like an action. They are like "--create-makefile".

If the text must be in the command line, it would be possible to do:

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

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

Then again, we have a clear command/action.

About splitting LazBuild:
It uses units which are also used by the IDE. Many of them depend on LCL while they should not. For example units dealing with a project and with a package should not depend on LCL.
The underlying code should be split into packages and dependencies should be reduced. It is an unbelievably hard task.

That is off topic. And not a requirement for the current add-on. (And - in some years - maybe achieved by the concept of ide/packages, that has now been started)

[Martin_fr]

To summarize (so we can agree an something, before further work is done).

I propose
(either one option can be done on its own, or both can be done)

Option 1)

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

1. lazbuild --dry-run   --show-macro-values
2. lazbuild --dry-run   --show-macro-values=TargetCPU,TargeOS

requiring "--dry-run" and "not parsing text"


Option 2)
read from STDIN:

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

1. lazbuild --replace-macros-in-text    < input.txt
2. echo "foo($TargetOS) | lazbuild --replace-macros-in-text

Optional (i.e. STDIN must be supported anyway)

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

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

If --input-text is given, it replaces STDIN, (STDIN will then be ignored)

Opinions?


--- EDIT: dropped requirement for STDIN

[440bx]

Just in case some of these suggestions might be helpful, maybe one of these "keywords" ...

expand
resultof

or some combination of the above with other words