Improvments

[Magnus Bodin]

Hi,

I have some improvement suggestions below that would ease working with tup a lot. At least when converting makefile projects into tup projects. Maybe its because I am "thinking make" that causes me to want these features but I never seem to find a good workaround for the missing functionality. Possibly my issues are caused by generating quite a lot of intermediate files during compilation that are written to a new tree-structure.

1. Add a %F flag that gives the whole path without the extension. I can't count how many times I wanted this flag.
   
2. Handling of \ vs / on Windows. I can't get this right for some reason. (Guess this is more of a bug than a improvement) Take this example
   
   |> echo "aaa\bbb" >> %o |> tmp.txt
   
   Seems impossible to get exactly "aaa\bbb" written to the file tmp.txt regardless of the number of \ I add to escape the conversion to /. I'll guess tup interpret "aaa\bbb" as a path and changes the last \ to /. A stand alone \ isn't converted.
3. Some lighter versions of string manipulations. Like converting a string to upper or lower case. Replace a substring etc.
4. A way to specify a specific outputfile in rules where we have multiple output files. E.g:
   
   input.txt |> splitfile -i %f -x %1o  -r %2o |> part_1.xml part_2.res
   
   splitfile will produce two output files (xml and a resource file) and it would be nice if it would be possible to specify a specific output file in the arguments to the command. It's nice if the output files also contains a path which makes the rule very long.
   
   This is related to a possible defect on Windows when using variants. I don't know how output files are handled on windows. I have seen some strange behavior when trying to compile with cl and specifying both object file output and exe-file output. (Both with a whole path.) The path seems to be ignored and the output files doesn't end up in the variant folder. Instead it's always written to the source tree which will give conflicts between variants. (Maybe related to 2?)
   
   I think I have to abandon variants for now and try to get it to work for the non-variant case first.

Would be nice to here what you think of my suggestions above. Maybe some have already been addressed in other threads but I couldn't find it. I'll have a look at tup source and see if I can make some modifications myself.

[Freddie Chopin]

On 01/30/2015 04:34 PM, Magnus Bodin wrote:
>
> 1. Add a %F flag that gives the whole path /without/ the extension. I

> can't count how many times I wanted this flag.

> 2. ...
> 3. Some lighter versions of string manipulations. Like converting a

> string to upper or lower case. Replace a substring etc.
>

The two above are possible with LUA parser.

> 4. A way to specify a specific outputfile in rules where we have
> multiple output files. E.g:

This is also possible with LUA parser, because instead of the old syntax
you can write regular functions which take arguments, so in your
function you'd have easy access to both outputs if you pass them as
arguments.

You can look for inspiration here -
https://github.com/DISTORTEC/distortos/blob/master/Tuprules.lua . The
functions actually still use %o and most of them don't have multiple
outputs, but to do what you want just replace uses of "%o" (or any other
flag) with the string variable output (or any variable you actually
need) - from there just extend the functions to use many variables
(coming from function arguments) in any place you want.

Regards,
FCh

[Magnus Bodin]

Yes, it's very much possible to do these things with lua. But to me these operations are quite common and to involve lua scripts is a bit of a hassle instead o having a extra flag etc. The simplicity of tup somehow get lost when I need to write my own lua scripts for common operations. But maybe they are only common for me. These improvements would make things easier for lua newbies like me and probably easier when porting from other buildsystems.

> --
> --
> tup-users mailing list
> email: tup-...@googlegroups.com
> unsubscribe: tup-users+...@googlegroups.com
> options: http://groups.google.com/group/tup-users?hl=en
> --- You received this message because you are subscribed to a topic in the Google Groups "tup-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/tup-users/yTVAUYsFj_E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to tup-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Zoltan Gaal]

1. Add a %F flag that gives the whole path without the extension. I can't count how many times I wanted this flag.
   
2. 
   

Here is a small patch that extends the lua parser with a %F flag. Patch may contain errors as I could not test some (commented out) part.

Also a bug in %B %b %e (according to my understandings) has also been resolved, as invalid input with multiple files were accepted by the parser:

tup.rule( '*', 'echo %o', '%B.%e' )                -- it should fail as %B and %e has no "valid" meaning in this case.
tup.foreach_rule( '*', 'echo %o', '%B.%e' )  -- it is legal and works as expected

Please feel free to update/comment the patch. And please apply to the git repo if applicable. 

Regards Gzp.

PS: The parser.c was not modified. If I were the tup maintainer I'd drop the parser as soon as possible in favor of lua.