makepp has a really nice feature that if I run a program or script in making a file, the file automatically depends on that program.
So
a_file:
myscript.sh >a_file
Will know that when myscript.sh changes, a_file should be remade. As far as I saw, if I call a script through system() in perl, then those programs are not registered.
so
a_file:
perl {{
system( "myscript.sh >a_file" )
}}
will not know the dependence between a_file and myscript.sh. If there a way for perl to register such a dependence? Some function to call instead of "system"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. makepp parses this before running the command, so it would also know in your original rule to create myscript.sh if necessary, as well as <file redirection.
2. the task would be endless, parsing perl for anything that might define a dependency (open my $fh, 'file'; open my $cmd, '|cmd …'), not counting that it could happen in a called function.
regards - Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see. So this is a similar problem to the question posted before about the compiler knowing better about dependencies than a scanner.
It is really a problem that inside makepp you don't have enough power to do stuff like loops in the commands, or setting variables, and then you need to use perl for that.
There is a "hacky" solution to this, which would be a way that you can help the scanner by marking a certain system command, and not allowing very complicated things.
Every file also depends on the command that creates it. It must be also true that that command has to be parsed before running the it, to decide if anything should be run at all…. I see how this breaks things. And why you can't have too much power.
Another ugly solution would be at that point for makepp to realize that it also needs myscript.sh, stop the current process, and start making myscript.sh
Or, that one can have perl code that is run twice. Once to figure out the dependecies, and once for the real run, and during the dependencies this special system command doesn't do anything. Of course perl code can have many other side effects, and it would be very surprising to get them twice.
I guess one could define makeperl, perl, and beforemakeperl, or some such. And beforemakeperl is defined to have less power, but be multifunctional.
I don't know. It seems I want power, but if I get it I'll be able to abuse it. I think I read a book like this once.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For and while loops have been specified (see "Just makepp it!" on our homepage) but not implemented. Also I would like to have equivalent &ifdef, &while, etc. at rule runtime level. Volunteers welcome!
As for your ideas, makepp makes it's decisions, then delegates the work (running the rule) to an independent subprocess. All that comes back is a return code (and with -j the collected stdout and stderr). For the :include case there is one more agreed return, the generated include file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
makepp has a really nice feature that if I run a program or script in making a file, the file automatically depends on that program.
So
a_file:
myscript.sh >a_file
Will know that when myscript.sh changes, a_file should be remade. As far as I saw, if I call a script through system() in perl, then those programs are not registered.
so
a_file:
perl {{
system( "myscript.sh >a_file" )
}}
will not know the dependence between a_file and myscript.sh. If there a way for perl to register such a dependence? Some function to call instead of "system"?
Hi Gently,
sorry, there are two problems with this:
1. makepp parses this before running the command, so it would also know in your original rule to create myscript.sh if necessary, as well as <file redirection.
2. the task would be endless, parsing perl for anything that might define a dependency (open my $fh, 'file'; open my $cmd, '|cmd …'), not counting that it could happen in a called function.
regards - Daniel
I see. So this is a similar problem to the question posted before about the compiler knowing better about dependencies than a scanner.
It is really a problem that inside makepp you don't have enough power to do stuff like loops in the commands, or setting variables, and then you need to use perl for that.
There is a "hacky" solution to this, which would be a way that you can help the scanner by marking a certain system command, and not allowing very complicated things.
Every file also depends on the command that creates it. It must be also true that that command has to be parsed before running the it, to decide if anything should be run at all…. I see how this breaks things. And why you can't have too much power.
Another ugly solution would be at that point for makepp to realize that it also needs myscript.sh, stop the current process, and start making myscript.sh
Or, that one can have perl code that is run twice. Once to figure out the dependecies, and once for the real run, and during the dependencies this special system command doesn't do anything. Of course perl code can have many other side effects, and it would be very surprising to get them twice.
I guess one could define makeperl, perl, and beforemakeperl, or some such. And beforemakeperl is defined to have less power, but be multifunctional.
I don't know. It seems I want power, but if I get it I'll be able to abuse it. I think I read a book like this once.
About (not) understanding perl, read http://search.cpan.org/~adamk/PPI-1.213/lib/PPI.pm#Background
For and while loops have been specified (see "Just makepp it!" on our homepage) but not implemented. Also I would like to have equivalent &ifdef, &while, etc. at rule runtime level. Volunteers welcome!
As for your ideas, makepp makes it's decisions, then delegates the work (running the rule) to an independent subprocess. All that comes back is a return code (and with -j the collected stdout and stderr). For the :include case there is one more agreed return, the generated include file.