VSLICKERRORPATH question what that directory doesn't exist yet

[rowbearto]

I'm trying to use VSLICKERRORPATH so that it can be used to find files with errors, and I'm mostly successful, except for a certain case.

On my very first build after cloning a repo, the directory that all compilation errors will be relative to does not yet exist. It will get created by the build script.

My understanding is that VSLICKERRORPATH will get set to the directory where the build command is run, and this is set in either:

The value in Tools->Build, "Run from dir"
or
Project->Properties "Working Directory" when the "Run from dir" option in Tools->Build set to "%rw"

But when this directory does not yet exist, I get errors when the build starts:

Code: [Select]

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
chdir: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

Now my build script still executes as I provide an absolute path to that in "Tools->Build->Command line" and the build script is coded such that it properly functions no matter which directory it is run from.

But in this case where the directory doesn't yet exist, the error parsing is taking me to the wrong file (I have multiple main.c in my project, it brings me to the wrong main.c, not the one with the error).

However if the build directory does exist at the start of the build, then the error parsing is finding the correct main.c.

So how to set the VSLICKERRORPATH to a directory that may not exist at the time the build starts? Can it be different than the directory used for "run from dir"?

So I found I can set it from the "Advanced" button for the "Build" tool, but there are 2 problems I encountered here:

1) I want to specify it relative to the project directory. But if I use %rp in the setting of the environment variable, the %rp does not expand to the project directory.
2) I would have to set VSLICKERRORPATH 2 times instead of just 1 time, for each of "Rebuild" and "Build"

Then I tried to add the build directory to the list of "Includes" in Project->Properties->Directories, but that doesn't seem to be working. The error parsing is taking me to the wrong main.c Even using the absolute path and not using a %rp, it doesn't seem to find it this way. It would be nice if %rp could be used in this list, but not sure if that will work?

[Clark]

When does your build directory that your files are relative to get created? Is the directory creation part of a build script that you have control over?

You can print out your own value for VSLICKERRORPATH in a customized build script at any time instead of relying on SlickEdit to know and print the correct value.

[rowbearto]

The directory creation is part of the build script, it is one of the first things it does. I do have control over it but there are also many others who use it who don't use SlickEdit. So I'd rather not put a SlickEdit specific thing in that script, although I suppose I could add a non-default command line switch to print it out. But I'd rather not as I may get questions about it. If there is another way?

[Clark]

how about running a script which runs your script

[rowbearto]

I suppose I could have another script print it out.

Is there a way to specify multiple directories to try as the base for relative paths inside the VSLICKERRORPATH? If so how?

Some of the build scripts I use invoke multiple makefiles each from different working directories.

[Clark]

currently it only supports one path

[rowbearto]

Was wondering if SlickEdit could add a little more intelligence about how to find the file when using VSLICKERRORPATH doesn't find it?

For example, my project has many files named "main.c".

The error messages are typically of the form:

../dir1/src/main.c
../dir2/src/main.c

SE is currently displaying the first (in the project list) main.c to display the error, which is often the wrong one.

But maybe SE can somehow look at the path starting from the right, picking the "main.c" in the project that most matches the path in the error message? So if SE sees the "dir2", SE could display the main.c from "dir2" instead of the main.c from "dir1" ?

[Clark]

I like that idea. At least it would be a better guess.

[Clark]

Try loading this and seeing if it does the trick for you.

[rowbearto]

Clark:

Thank you so much! It certainly does do the trick. +1

Will it be in the next hotfix?

Thanks again!

[Clark]

Glad that works. I'll add this to our hot fixes. It was pretty easy to add. I've made one tweak to it. I added an _isRelative(filename) if statement around the code so it won't bother if the filename is absolute. It's just a minor performance optimization.

[tourix]

Thanks for attempting to fix this issue that has annoyed me for years.
However, the hot fix in projutil.e is still not working for me and a file with the wrong path (but correct filename) is often opened to display the next error.
For example, if the error message shows "foo/bar2/baz", and the project contains both "foo/bar/baz" and "foo/bar2/baz", the wrong file "foo/bar/baz" will be opened.
Looking at the source, I am curious as to why 0 is passed to checkPath:
  found_filename = _projectFindFile(_workspace_filename, _project_name, temp_filename, 0, (int)returnAll,1);

Actually, I do not know the proper way to edit a system macro in order to try to pass 1 to checkPath.

Thanks!

[Clark]

Can you post a small project that illustrates this problem. No real build command is necessary (just use dummy source files too). Usually I just set the build command to something that dumps a text file with an error message (type errorsample.txt or cat errorsample.txt). I'm not sure I follow exactly what's going wrong in your scenario.

[Clark]

Make sure you have the hot fix loaded.

https://customer.slickedit.com/support/product-updates/hotfixes

Help>Product Updates>Load Hot Fix...

[tourix]

Yes, I loaded hotfix 12 earlier and yesterday hotfix 14, both containing the fix.
Sorry, but I cannot post a project for security reasons, however, I already posted all pertinent info.
I am running on Debian. Make sure the capturing group from the build error contains "foo/bar2/baz" as the filename (not starting with "../", "./", or "/").
The project contains both "foo/bar2/baz" and "foo/bar/baz".

Back to my question about the 'checkPath' argument passed to '_projectFindFile'. Why is it not 1?
And what is the simplest way for me to edit 'projutil.e'? Do I have to patch and load a hotfix? Or is there a more direct way? (I know this is not recommended to modify system macros).
Thank you