first let me thank for the nice Makepp! I have introduced it in our company since Septembre 2006. In that time I have written a framework around makepp to allow our Makeppfiles to be seen as simple templates that have to include two another files (one at the top and one at the bottom) which will do the remaining tasks.
In that framework it was necessary to write some new make functions, commands and even statements to support our complicate build structure. I have to add, that before Makepp we were using ClearMake resp. GNU-Make and the conversion to Makepp should be as least intrusive as possible to allow for automatic (or better no at all) conversion of the existing Makefiles.
Among the statements I have written, there is a 'foreach' statement that can be used like:
foreach m $(MAKEFILES)
# do something with $(m)
endfor
and 'call' that allow to handle a string as a macro like e.g. this:
define WARN
&echo "***WARNING: '$1'"
enddef
call WARN, "This is the text I want to warn you with"
Unfortunately to realize these both statements, I had to use a dirty trick to write those texts into an temporary file and then including them back into the Makeppfile via
Makefile::read_makefile($makefile,...);
But this is a bit slow due to the amount of Makeppfiles one single build will parse and load. So I have split Makefile::read_makefile into Makefile::read_makefile and Makefile::parse_makefile, whereby the first one call the second one at its end. Using this, I can avoid to write my macro text to a temporary file by passing it into Makefile::parse_makefile as string directly ...
My question now would be, if you would accept my Makefile::parse/read_makefile patch? Furthermore I would like to ask, if you are interested in the new statements I mentioned above? If you accept, how would I have to contribute those patches?
Thanks in advance for your consideration. Please keep up your work on Makepp!
Best regards,
Clemens Hintze. (c(dot)hintze(at)gmx(dot)net)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As for the call statement, for compatibility it would be better instead to have a call function as in GNU make. You could then use makepp's early expansion syntax $[call WARN,param,...] at a makefile's top level to perform statements like &echo while reading the makefile.
If you'd like to provide f_call, I don't see a problem to put it into makepp. If not, you could write your own statement function s_warn, which would do just what you need.
liebe Grüße
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for your hint to the extension plan. This looks really very promising! As for the syntax $[] I have to admit, that I did recognize that syntax but I did not recognize the possibility to use it for right that purpose you proposed. I feel a bit dense now :-}
I already had a function 'f_call' for some time! And now using it together with $[] fits my problem exactly, so that I can forget about my call statement :-)
I would like to provide 'f_call' and if you don't bother, I would also like to provide a function 'f_catch' that can be used to catch any error a builtin function may raise (e.g. $(find-upwards)). If a function raise an error, 'f_catch' would silence the error and simply return an empty string.
So if you like, please include them into makepp under the same license as makepp itself! However, if the code does not fit your quality demand, please let me know and I will try to improve!
Thanks for the call function. Alas life is not so easy: Could you please add at least a test case in variable_expansion.test(misc_gnu_make_functions), and if possible fix pod/makepp_incompatibilities.pod and provide a "New function." ChangeLog so we can give credit to you?
Concerning catch, I had considered something similar, namely, like for rule actions, to be able to precede a function call with - or ignore_error. But looking through the functions, I found that, apart from parameter errors, hardly any of them die. Like gmake's realpath function, we should maybe convert the two exceptional cases to returning an empty string instead?
liebe Grüße
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
concerning 'f_call': I will do the additions you requested. I would send them to you as a patch against latest CVS? Do you want me to introduce 'f_call' somewhere in the source (e.g. Makesubs.pm) and deliver it included in the patch as well (one big patch)? Should I attach the patch here in a follow-up or dou you want me to send it to you attached in an email?
Concerning 'f_catch': I had not checked, how many functions would die except for parameter errors. 'find-upwards' simply disturbed me and so 'f_catch' was born! :-) If you say, that there are only two functions, I think it would be desirable to change them not to die and returning an empty string. Then we would have no real need for 'f_catch' ... But if you decide that way, would you please consider, that 'f_find_upwards' will also work this way:
shall return the paths to 'some/existing/location' and to 'another/existing/one' hereby silently ignoring the fact, that it didn't find 'not/existing/location' anywhere. It would not helpful, if 'f_find_upwards' would return an empty string for its whole work, only because one of several locations didn't succeed.
What do you mean?
Thanks for your help.
Ciao,
Clemens.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I now have fiddled out, how to write tests for makepp. I have stolen some tests from the testsuite of GNU make 3.81. But I had to modify 'f_call' a bit as I did not consider constructions like '$$1', '$(1)', '${1}' or '$0' correctly. But now it do :-)
But I had also to remove 'answers/n_files' from 'variable_expansion.test' as it somehow interferes with the tests (at least run_tests.pl has complained).
While I was working on 'f_call' I suddenly had a further idea. What about a further makepp extension that allow to $(call) contents of a variable if it has the syntax of an function call? That mean:
my-grep = $(filter $1,$2)
result := $(my-grep a b c, a d e f)
whereby the last line would be handled as it was written like:
result := $(call my-grep,a b c, a d e f)
But as it was a sudden idea, I have not thought thru all consequences. So please let me know your opinion!
Gxis revido,
Clemens.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't remove 'answers/n_files'! Adapt it to reflect the number of files you build, instead.
It was a good idea to base your test on an existing one and fixing the bugs that showed up that way! Definitely submit the patch against the latest CVS version by mail attachment (this forum breaks formatting), and I will submit the changes for you.
Concerning the alternate call syntax you propose, it sounds like a nice idea, and shouldn't be too hard to do. But given that gmake macros are fairly primitive compared to real functions as you can do them in makepp, I'm not sure it's worthwhile. Maybe someone else would like to comment?
Ĝis revido
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bonvolu pardoni mia eraro, sed mi ne tre bone parolas Esperanton!
I will tell you a bit more in my private email I will send to you with my patch. :-)
I did not remove 'answers/n_files' now! I guess, as I was not used to the test framework, I got several things wrong, so that 'n_files' caused the tests to fail. But I hope, now I have fiddled all these things out. I had also to patch 'install.pl' to allow '$(catch)' to be highlighted like any other built-in keyword.
Although macros are fairly primitive compared to real functions, I still prefer them for simple tasks like e.g.
downcase = ${perl lc("$1")}
and some other more. I use real functions only, if the task is very complex or cannot be done with makepp built-in functions. And given e.g. the definitions above, a
$(downcase $(MYWORDS))
simply looks prettier than
$(call downcase, $(MYWORDS))
But these are only my two cents :-)
I will sent the email with the path to your email address given in the ChangeLog. Please complain here, if this is not the right one.
Ĝis revido,
Clemens.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried to send my patch two both of you email addresses I know (occitan and pfeiffer) but both did bounce with an error "no such user" or similar. So I seem to have no possibility to send you the patch.
Could you perhaps send me an email with another (working) email address to
c .dot. hintze .at. gmx .dot. net
? Thanks in advance!
Best regards and
Ĝis revido,
Clemens.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
first let me thank for the nice Makepp! I have introduced it in our company since Septembre 2006. In that time I have written a framework around makepp to allow our Makeppfiles to be seen as simple templates that have to include two another files (one at the top and one at the bottom) which will do the remaining tasks.
In that framework it was necessary to write some new make functions, commands and even statements to support our complicate build structure. I have to add, that before Makepp we were using ClearMake resp. GNU-Make and the conversion to Makepp should be as least intrusive as possible to allow for automatic (or better no at all) conversion of the existing Makefiles.
Among the statements I have written, there is a 'foreach' statement that can be used like:
foreach m $(MAKEFILES)
# do something with $(m)
endfor
and 'call' that allow to handle a string as a macro like e.g. this:
define WARN
&echo "***WARNING: '$1'"
enddef
call WARN, "This is the text I want to warn you with"
Unfortunately to realize these both statements, I had to use a dirty trick to write those texts into an temporary file and then including them back into the Makeppfile via
Makefile::read_makefile($makefile,...);
But this is a bit slow due to the amount of Makeppfiles one single build will parse and load. So I have split Makefile::read_makefile into Makefile::read_makefile and Makefile::parse_makefile, whereby the first one call the second one at its end. Using this, I can avoid to write my macro text to a temporary file by passing it into Makefile::parse_makefile as string directly ...
My question now would be, if you would accept my Makefile::parse/read_makefile patch? Furthermore I would like to ask, if you are interested in the new statements I mentioned above? If you accept, how would I have to contribute those patches?
Thanks in advance for your consideration. Please keep up your work on Makepp!
Best regards,
Clemens Hintze. (c(dot)hintze(at)gmx(dot)net)
Moin Clemens,
please note an extension plan described under http://makepp.sourceforge.net/just_makepp_it/makepp_erweiterung.html#1__parser_reimplentierung_mit_while_und_foreach which collides with your planned statement.
As for the call statement, for compatibility it would be better instead to have a call function as in GNU make. You could then use makepp's early expansion syntax $[call WARN,param,...] at a makefile's top level to perform statements like &echo while reading the makefile.
If you'd like to provide f_call, I don't see a problem to put it into makepp. If not, you could write your own statement function s_warn, which would do just what you need.
liebe Grüße
Daniel
Moin Daniel,
thank you for your hint to the extension plan. This looks really very promising! As for the syntax $[] I have to admit, that I did recognize that syntax but I did not recognize the possibility to use it for right that purpose you proposed. I feel a bit dense now :-}
I already had a function 'f_call' for some time! And now using it together with $[] fits my problem exactly, so that I can forget about my call statement :-)
I would like to provide 'f_call' and if you don't bother, I would also like to provide a function 'f_catch' that can be used to catch any error a builtin function may raise (e.g. $(find-upwards)). If a function raise an error, 'f_catch' would silence the error and simply return an empty string.
So if you like, please include them into makepp under the same license as makepp itself! However, if the code does not fit your quality demand, please let me know and I will try to improve!
Thanks for you help.
Ciao,
Clemens :-)
sub f_call {
my ($args, $makefile) = @_;
my ($var, @args) = split(/ *, */, $args);
return "" unless $var;
my ($_reexp, $res) = $makefile->expand_variable($var, undef, 1);
return "" unless $res;
$res =~ s!\$(\d+)!(($1-1)>$#args ? "" : $args[$1-1])!ge;
$res ? $makefile->expand_text($res) : "";
}
sub f_catch {
my ($args, $makefile, $mfline) = @_;
my ($fn, @fnargs) = split(/\s*,\s*/, $args);
my $res = "";
eval {
no warnings 'all';
my $cmd = sprintf('$(%s %s)', $fn, join(',', @fnargs));
$res = $makefile->expand_text($cmd, $mfline);
};
return $res;
}
Moin Clemens,
Thanks for the call function. Alas life is not so easy: Could you please add at least a test case in variable_expansion.test(misc_gnu_make_functions), and if possible fix pod/makepp_incompatibilities.pod and provide a "New function." ChangeLog so we can give credit to you?
Concerning catch, I had considered something similar, namely, like for rule actions, to be able to precede a function call with - or ignore_error. But looking through the functions, I found that, apart from parameter errors, hardly any of them die. Like gmake's realpath function, we should maybe convert the two exceptional cases to returning an empty string instead?
liebe Grüße
Daniel
Not to forget and index entry and a description in pod/makepp_functions.pod
Moin Daniel,
concerning 'f_call': I will do the additions you requested. I would send them to you as a patch against latest CVS? Do you want me to introduce 'f_call' somewhere in the source (e.g. Makesubs.pm) and deliver it included in the patch as well (one big patch)? Should I attach the patch here in a follow-up or dou you want me to send it to you attached in an email?
Concerning 'f_catch': I had not checked, how many functions would die except for parameter errors. 'find-upwards' simply disturbed me and so 'f_catch' was born! :-) If you say, that there are only two functions, I think it would be desirable to change them not to die and returning an empty string. Then we would have no real need for 'f_catch' ... But if you decide that way, would you please consider, that 'f_find_upwards' will also work this way:
$(find-upwards some/existing/location not/existing/location another/existing/one)
shall return the paths to 'some/existing/location' and to 'another/existing/one' hereby silently ignoring the fact, that it didn't find 'not/existing/location' anywhere. It would not helpful, if 'f_find_upwards' would return an empty string for its whole work, only because one of several locations didn't succeed.
What do you mean?
Thanks for your help.
Ciao,
Clemens.
Bonan morgaux Daniel,
I now have fiddled out, how to write tests for makepp. I have stolen some tests from the testsuite of GNU make 3.81. But I had to modify 'f_call' a bit as I did not consider constructions like '$$1', '$(1)', '${1}' or '$0' correctly. But now it do :-)
But I had also to remove 'answers/n_files' from 'variable_expansion.test' as it somehow interferes with the tests (at least run_tests.pl has complained).
While I was working on 'f_call' I suddenly had a further idea. What about a further makepp extension that allow to $(call) contents of a variable if it has the syntax of an function call? That mean:
my-grep = $(filter $1,$2)
result := $(my-grep a b c, a d e f)
whereby the last line would be handled as it was written like:
result := $(call my-grep,a b c, a d e f)
But as it was a sudden idea, I have not thought thru all consequences. So please let me know your opinion!
Gxis revido,
Clemens.
Bonan matenon Clemens (morgaŭ eq tomorrow)!
Mi ĝojas ke vi lernas Esperanton! :-)
Don't remove 'answers/n_files'! Adapt it to reflect the number of files you build, instead.
It was a good idea to base your test on an existing one and fixing the bugs that showed up that way! Definitely submit the patch against the latest CVS version by mail attachment (this forum breaks formatting), and I will submit the changes for you.
Concerning the alternate call syntax you propose, it sounds like a nice idea, and shouldn't be too hard to do. But given that gmake macros are fairly primitive compared to real functions as you can do them in makepp, I'm not sure it's worthwhile. Maybe someone else would like to comment?
Ĝis revido
Daniel
Bonan matenon Daniel,
bonvolu pardoni mia eraro, sed mi ne tre bone parolas Esperanton!
I will tell you a bit more in my private email I will send to you with my patch. :-)
I did not remove 'answers/n_files' now! I guess, as I was not used to the test framework, I got several things wrong, so that 'n_files' caused the tests to fail. But I hope, now I have fiddled all these things out. I had also to patch 'install.pl' to allow '$(catch)' to be highlighted like any other built-in keyword.
Although macros are fairly primitive compared to real functions, I still prefer them for simple tasks like e.g.
downcase = ${perl lc("$1")}
and some other more. I use real functions only, if the task is very complex or cannot be done with makepp built-in functions. And given e.g. the definitions above, a
$(downcase $(MYWORDS))
simply looks prettier than
$(call downcase, $(MYWORDS))
But these are only my two cents :-)
I will sent the email with the path to your email address given in the ChangeLog. Please complain here, if this is not the right one.
Ĝis revido,
Clemens.
Hello Daniel,
I have tried to send my patch two both of you email addresses I know (occitan and pfeiffer) but both did bounce with an error "no such user" or similar. So I seem to have no possibility to send you the patch.
Could you perhaps send me an email with another (working) email address to
c .dot. hintze .at. gmx .dot. net
? Thanks in advance!
Best regards and
Ĝis revido,
Clemens.
The call function has long been implemented, some time ago the suggested $(macro …) syntax added and more recently fixed so it can be used as $.