Community
Participate
Working Groups
There are various MBS built in macros which evaluate to directories on the file system or in the project (e.g. ${OutputFileRelPath}). The current implementation forces there to be a trailing separator. This is a problem for me because the trailing separator is currently always OS specific, and can screw up the shell because on Windows I get a backslash, which can sometimes escape the next character depending on what character it is(in my case a quote). Since I'm using the macro in my dependency calculator, I can't modify the value to strip off the separator. Right now as a temporary hack I've been forced to modify the macro supplier to not add the trailing separator. Wherever I need to, I concatenate the path with the / character to get an OS neutral path. There are a few ways I can think of to tackle this, each with pros and cons: Possible solution 1: For each of these macros there be two versions: one with a trailing separator (e.g. ${OutputFileRelPath}) , and one without (e.g. ${OutputFileRelPathNoTrailingSep} or some other appropriate name. This means a lot of macros with long names however, and doesn't give you an OS neutral trailing separator if you need one. I can forsee though that the Windows OS separator might screw up CygWin at some point. Possible solution 2: Make the trailing separator OS neutral. However, if you truly need the separator to be gone, this doesn't help you. Also, what if you really do need an OS path? Possible solution 3: Combine both 1 and 2. Thoughts?
Hi Chris, I see two problems here: 1. Some MBS built-in macros that represent paths do have trailing separators at the end (e.g. OutputDirRelPath), while other do not (e.g. ProjDirPath). We might need to come to some common convention regarding directory path representation. I suppose the directory paths should be presented without trailing separator at the end, so we might need to remove the trailing separators for all MBS built-in directory path macros that currently have separator at the end. 2. The other problem is in special treating the back-slashes by the shell and the builder. I mean you will probably encounter the same problem in case you have the back-slash somewhere in the middle of the path, not just with the trailing slash, won’t you? We might define some mechanism to tell MBS what path separator should be used when and generate the path build macros accordingly. The main problem I see is that the way slashes/back-slashes are treated (what character (slash or back-slash or both) is treated as a path separator and whether the back-slash is used for escaping) may differ for the builder, shell and tools used for building. I also suppose that this might be more general problem than just build macro related, see e.g. bug# 113279, so we probably need to think bout some solution for fixing the slash/back-slash issue in general. We should decide how deep we should go in resolving this issue, e.g. for fixing the problem you are mentioning here, we might define some new builder attribute that would tell build macro provider what delimiter to use for the path macros. Or if we decide we need to handle the cases that tools and builder may treat slashes/back-slashes differently (could be useful in case of substituting/adding/changing tools/builder in the tool-chain), than we might probably need some per-tool/builder setting, e.g. some attribute that would specify the path delimiter to be used for each tool/builder, etc. Also note that the buildfile generator will have to treat those settings respectively while buildfile generation. What do you think? Thanks, Mikhail
