Slight improvement for lazbuild

[n7800]

If in doubt, see the help:

Code: [Select]

--create-makefile
        Instead of compile package, create a simple Makefile. No support for build modes. Does not compile required packages.
Everything is written. We cannot do more for the user (at least in this situation).

[Martin_fr]

If in doubt, see the help:

Code: [Select]

--create-makefile
        Instead of compile package, create a simple Makefile. No support for build modes. Does not compile required packages.
Everything is written. We cannot do more for the user (at least in this situation).

Being able to use the help wasn't the question.

You initially wrote " It is still absolutely clear", now you write "if in doubt", i.e., there can be doubt and it is all but not absolutely clear.

I have no issues if you want a solution that has flaws, fully accepting those flaws (I do the same with the solution I brought up).
Just don't write they aren't there....

[zamtmn]

Gentlemen, you're making things too complicated. All we need to do is get the macro values from the project. Reworking and assigning logic to lazbuild parameters is another task

[n7800]

In the first line everything is correct, but in the second line the file and command are "rearranged". And so what? It is still absolutely clear what the user wanted. I see no reason to call such a command invalid.

Really? What does he want to do?

Does he want to perform the default action (build), but in a modified way (create a makefile, and build using that)?

Everything is clear to me, but you doubted it)) There is only one command ("action") in the line, and there are no ambiguities.

I have no issues if you want a solution that has flaws, fully accepting those flaws (I do the same with the solution I brought up).
Just don't write they aren't there....

Please note that it is a difficult for me to write in English, perhaps the translator will somewhat exaggerate what I wanted to say. It is clear that we are trying to find the "lesser evil".

Gentlemen, you're making things too complicated. All we need to do is get the macro values from the project. Reworking and assigning logic to lazbuild parameters is another task

As we found out, we could get a lot of information from lazbuild. And the question is how best to obtain this data. Implementing the functions themselves is not difficult, lazbuild already knows how to do this, you just need to output this data.

Of course, the command line format is secondary. I'm ready to accept any format as long as it works. I just decided to share my options.

[TRon]

    lazbuild --create-makefile project1.lpi
    lazbuild project1.lpi --create-makefile

Everything is clear to me, but you doubted it)) There is only one command ("action") in the line, and there are no ambiguities.

My project is named --create-makefile the second project is named project1.lpi

I wish to build project1.lpi and based on the project settings create a makefile as well so that next time I can use make (or fpmake) instead of lazbuild.

And why would there be need to include a template parser in lazbuild itself ? There are plenty enough 3th party template parsers so all lazbuild need to do is pipe the defines/vars to something suitable (hence my mentioned preference for a separate command that does not add unnecessary bloat to lazbuild. The bloat is one thing but it also has to be maintained.

[n7800]

    lazbuild --create-makefile project1.lpi
    lazbuild project1.lpi --create-makefile

Everything is clear to me, but you doubted it)) There is only one command ("action") in the line, and there are no ambiguities.

My project is named --create-makefile the second project is named project1.lpi

This problem affects any command line. If you want to use a filename starting with "-" or "--", then just put it in quotes. It is good practice to quote any name at all, even if it does not contain spaces or other special characters.

I wish to build project1.lpi and based on the project settings create a makefile as well so that next time I can use make (or fpmake) instead of lazbuild.

For these purposes, Martin suggested:

Btw, about the idea with multiple commands, something like this would work (and probably even be compatible with what we currently have, at least so long as current syntax has one action only

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

1. lazbuild   [options for all actions]  ACTION-1 [options for action 1 only]  ACTION-2 [options for action 2 only]

Yes of course that can be done with the --get-.. --update-... style. But that be really bad...

There could be a divider between actions

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

1. lazbuild   [options for all actions]  -+- [options for action 1 only]  ACTION-1  [options for action 1 only]  -+- ACTION-2 [options for action 2 only]

Neither needs to be decided yet. If for now, the rule is: only one action, then both of the above will be backward compatible, if ever we would want them.

It seems to me that the only purpose that can be achieved with this syntax is to increase execution speed so that the file does not have to be reopened for each command. But it’s unlikely that lazbuild spends a lot of time on this.

And what if an error occurs on some "action"? How to find out which one? And is it necessary to continue working after this? And how can I find out which project is currently being compiled with messages? This will force you to add several more flags, making the syntax even more complex.

I think that for lazbuild this is not necessary. One line - one command. This is a command line interface - it should be simple so that it can be easily used in scripts.

By the way, this reminded me of the syntax of the "make" utility. At first I didn’t understand why the phrase "clean all" is always used for building ))

And why would there be need to include a template parser in lazbuild itself ? There are plenty enough 3th party template parsers so all lazbuild need to do is pipe the defines/vars to something suitable (hence my mentioned preference for a separate command that does not add unnecessary bloat to lazbuild. The bloat is one thing but it also has to be maintained.

This is not just parsing. Expanding macros is a more complex task, all the subtleties of which are unlikely to be known to a third-party application.

And lazbuild already does this, so there won't be any bloat and support for this particular feature won't be needed. Check out the original merge request:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/129
Getting the macro value is one line, everything else concerns command line parsing.

[JuhaManninen]

@n7800 and others, please check commit e0f086d2e0 and issue https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/29511

[n7800]

I think the --get-target-file option is redundant, since it can easily be replaced by calling --get-expand-text="$(OutputFile)".
By the way, there is a $(TargetFile) macro, but it is used for something else.

Moreover, macros allow you not only to get a path, but also to process it. For example, you can get only the dir of the target file: --get-expand-text="$Path($(OutputFile))"

In general, you can get a lot of information about a project through macros. In the future, we might even just add macros instead of changing lazbuild.

[n7800]

By the way, the text specified in --get-expand-text has no meaning if it does not contain any macros (the $ sign). This can be used as a special case, assuming that the name of the macro is simply specified. That is, the following commands are identical:
  --get-expand-text=$(OutputFile)
  --get-expand-text=OutputFile

This will reduce the length of the text and simplify its use in the terminal, eliminating many unnecessary characters.

But the main thing is that it will get rid of escaping problems in bash (see this). This is especially true for bash scripts, where people are likely to forget to escape the $.

[n7800]

It's funny, if you use the analogue of the abbreviation --primary-config-path to --pcp, then for --get-expand-text you get --get. In my opinion, it turns out well and even makes sense:
  lazbuild --get=OutputFile project1.lpi

[n7800]

Please check the attached patch series for my suggestions above.

[JuhaManninen]

I applied the 2. and 3. patch. Thanks.
Is removing --get-target-file necessary? It may be used by some people and it does not harm others.

[n7800]

This will simplify future support, and the user will not have to remember more parameters (there are already a lot of them in lazbuild).

Additionally, they may wonder why there is a separate function for getting the output file, but not a separate command for something else?

And look how confusing this can be:

Code: [Select]

lazbuild --get=targetfile project1.lpi
lazbuild --get-target-file project1.lpi
You can specify any macro in the first line, but not in the second line.

IMO I don't see any benefit to it...

[JuhaManninen]

OK, I applied it.