target.abspath returns a relative path

[premake]

target.abspath returns a relative path

I'm noticing this with file.abspath as well.

[samsinsane]

I believe this has been resolved by #880, closing based on this, please reopen if this doesn't fix the issue.

[tvandijck]

FWIW, Premake always tries to make all paths relative for properties that are not paths. For example the buildcommands, is just a string, since it contains a command line and not a path. Because the goal of premake is to allow the project to be moved around, it should basically only ever output relative paths into project files, so you can zip up the project, send it to someone without premake, and allow it to be unpacked and build.

This is the reason why using %{file.abspath} turns into a relative path inside of command line options. The PR that @samsinsane references, allows you to disable that by writing %{!file.abspath}, and while that works, it obviously also breaks the concept of movable projects.. So use with care.

[starkos]

I do agree with the original poster that the behavior of abspath is counterintuitive in this case. Ideally, Premake probably should just output the absolute path in this case and not require the '!'.

[tvandijck]

The Visual Studio action actually replaces it with a Visual Studio token. %(Fullpath) or something. Which is cool, because it keeps to the movable project goal. But it does result in inconsistent paths at times. In particular the "google protocol buffers" compiler can't handle mixed paths, which causes all kinds of trouble for us here.

I've contemplated just removing all the logic from the detoken function, and just do what people write. I'd be all for that, as it kind of demystifies the behavior of detoken. I'm getting about 2-3 emails a month about it here internally ;)

But I wanted to discuss that with the rest here first.. @starkos, @samsinsane.

[tvandijck]

And just to clarify this further, as much as I'd like to remove that, I'm also reluctant... for example

buildcommands {
	'cxc -c "%{file.path}" -o "%{cfg.objdir}/%{file.basename}.xo"',
	'c2o -c "%{cfg.objdir}/%{file.basename}.xo" -o "%{cfg.objdir}/%{file.basename}.obj"'
}

in on of the unit-test, it expects:

$(SILENT) cxc -c "hello.x" -o "obj/Debug/hello.xo"

which makes perfect sense, and is what I would like to maintain... The problem is however, if we remove the make relative behavior from detoken, it becomes:

$(SILENT) cxc -c "hello.x" -o "D:/dev-premake/premake-vendor/obj/Debug/hello.xo"

which is clearly less desirable.

Ideally, a buildcommand isn't just a string, but a list of objects. something like:

buildcommands {
    buildcommand { path('cxc.exe'), option('-c'), path('%{file.path}'), option('-o'), path('%{cfg.objdir}/%{file.basename}.xo')
}

it's just so inconvenient to write that...

[samsinsane]

That's an interesting idea, I feel that would be quite inconvenient to write though. I personally prefer the usage of !, it's simple and easy to use, sadly it's also really easy to forget about. Should we re-open this issue?

[starkos]

What if we add another value to the pathVars tables like makeRelative? And then use that value when setting dontMakeRelative in detoken.expand(), to prevent abspath replacements from getting converted? Does that clean things up?

[tvandijck]

One of the other ideas one of my colleagues had, was to do a late join. As in, instead of returning a string from detoken, we return an AST. Generally the AST is just a single string, but in the case where you do something like %{file.path} we know it's a path, so it could build a 'tree' of <string><path><string>..

The "action" gets to resolve it at the end, instead of the detoken trying to figure it all out.
it's a big refactor for sure, but I think it would allow us to get the best of both worlds.

@starkos I think that would allow us to control it for API's entirely, say buildcommands we set that flag, and it will never do the abspath replacement.. a useful addition for sure. Not sure how much it helps though. For some tokens you want it, for others you don't. It almost like if you write file.abspath then keep it abs.. but it you write cfg.objdir you don't want abs, unless you explicitly asked for it, like what file.abspath implies.

[starkos]

Hmm…maybe we can allow actions to register a "token expander" function, kind of like they can register a string escaping function now. If the action doesn't set one, then a default gets used. That might help reduce the amount of refactoring that is needed?