Is there a way to get the working directory of the lime project?

Lime
#1

I’m invoking my project like this:

/path/to/hello> haxelib run lime test windows

I’d like to get the path /path/to/hello, the place where I was when I invoked the compiler, but it doesn’t seem like there’s a way to do it.

I tried Sys.getCwd but it returns /path/to/hello/bin/windows/cpp/release/ which isn’t helpful.

I can’t find any other relevant method in the documentation. Have I missed it?

1 Like
#2

Further testing shows that a correct pwd path is returned for windows if you invoke the executable by hand. So presumably on windows it’s either haxelib or lime that is changing the working directory which is a little unwanted but whatever.

On OSX, I can’t find any workaround. Even if you run the app from the terminal it seems that getCwd() will ignore your pwd and just report the app’s own directory no matter where you are.

1 Like
#3

If you want to compile this information into the app, try using a macro:

public static macro function getProjectDirectory():String {
    return macro $v{Sys.getCwd()};
}

Then call getProjectDirectory(). Note: I haven’t tested this, so I don’t know if it’ll work.

#4

It doesn’t build.

Anyway I definitely don’t want to compile that information into the app, that’s the opposite of what I want. I want whatever folder the terminal was in when it invoked the app. I want the working directory, not the project directory.

#5

Oh, oops. It should return haxe.macro.Expr, not String.

Then Sys.getCwd() is your only option. (Short of spawning a subprocess that attempts to look at the state of all active Command Prompt instances.)

Since Lime calls cd before running your project, you’ll have to work around Lime. Run your project manually, typing out “bin/windows/cpp/release/AppFile.exe” (or whatever the correct path happens to be).

#6

I’d be happy with that workaround. I suppose in this case the way that lime executes the program isn’t really a problem for me in this case.

My biggest problem is that even bypassing lime doesn’t work on mac because the app clobbers its own cwd when it starts up.

I couldn’t find a workaround for this so I ended up writing a shell script to pass in the cwd as an argument.

#7

We need the current working directory to be the same as the executable to resolve relative asset paths, but if we make improvements to ensure that this is no longer necessary, then leaving the current working directory alone may be a better default behavior. Is this an OpenFL, or a Lime project?

The only concern I have is in user code that assumes the working directory is the same as the project, and therefore makes assumptions about reading and writing files outside of lime.utils.Assets

#8

Hello there, just starting with haxe and lime and I think this is incorrect or is the first time I see this behavior and is no the expected one nor from the developer or the user. Remember that the command line is used by lots of people and is very common that user refers to files using command line arguments and in general does it using relative path.

Besides that humble feedback the big question is, how this problem can be solved ? The only workaround I see is for the user to give absolute paths which basically breaks the command line interface experience for paths (users don’t have a practical why of writing absolute paths from the CLI).

Is there any way one can hook in before lime changes the CWD to store it? Should I report an issue
/ PR ? Here I’m with just lime project and reproducing this behavior both with lime test cpp or executing the generated binary from the command line.

Am I missing something? Any help is appreciated. Thanks in advanced.

#9

@player_03 snippet didn’t work for me but this does:

	public static macro function cwd():haxe.macro.Expr.ExprOf<String> {
		return macro $v{Sys.getCwd()};
	}

Hope it be of help

#10

Guess I should have edited it back when the issue was pointed out to me. At this point only an admin can edit the post.

Anyway, your solution is correct, as are these:

public static macro function cwd():haxe.macro.Expr {
    return macro $v{Sys.getCwd()};
}
public static macro function cwd() {
    return macro $v{Sys.getCwd()};
}

Since my old post, OpenFL took my suggestion to make a custom substitution available in project.xml. Normally substitutions just look up existing variables, but if you write ${projectDirectory}, it’ll look up the current working directory.

<haxedef name="compileTimeDirectory" value="${projectDirectory}" />

trace(haxe.macro.Compiler.getDefine("compileTimeDirectory"));
1 Like