Author Topic: [REGRESSION - 13.0.1] %rp for Build Dir ignored: builds from current dir instead  (Read 8000 times)

Ivan N. Zlatev

  • Community Member
  • Posts: 87
  • Hero Points: 5
I can't build my projects (that use a custom build tools) with 13.0.1 because the directory to run the build tool command from (%rp - project dir) is always ignored and instead the current file directory is used. I have def_change_dir set to 4 and def_switchbuf_cd set to 1 if that's somehow related.

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1249
  • Hero Points: 125
I'm not able to reproduce as with the information you've provided.  Could you provide some details on the command-line and properties for the custom build tools or example where this is not working?  And any info on how your source/project trees are organized would help.

Ivan N. Zlatev

  • Community Member
  • Posts: 87
  • Hero Points: 5
I can repro on a Linux box as follows:

1) svn co svn://anonsvn.mono-project.com/source/trunk/mwf-designer
2) Open Mono.Design.vpw
3) Set mwf-designer as Active Project
4) Open for editing from Mono.Design project for example the Mono.Design.sources file.
5) Build menu -> Build ...

Code: [Select]
/home/ivanz/bin/slickedit/bin/vsbuild -signal 9009 -command "make mono-design"
dograthea deps/Mono.Design> VSLICKERRORPATH=/home/ivanz/tmp/mwf-designer/deps/Mono.Design
make mono-design
make: *** No rule to make target `mono-design'.  Stop.

However if I invoke the build again it works:

Code: [Select]
dograthea tmp/mwf-designer> /home/ivanz/bin/slickedit/bin/vsbuild -signal 9009 -command "make mono-design"
VSLICKERRORPATH=/home/ivanz/tmp/mwf-designer
make mono-design
mkdir -p build
cd deps/Mono.Design && make
make[1]: Entering directory `/home/ivanz/tmp/mwf-designer/deps/Mono.Design'
python generate-mono-design.py

I have a feeling something goes wrong with the paths once I open a file not part of the active project (from the other project in this case)

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
%rp isn't working for me either when building.
It uses the directory of the current file instead.

SE 13.0.1 r20 on Vista with:
- def_switchbuf_cd = 1
- a workspace with multiple projects, each rooted at different directories

If the current file is from the current project, then building starts from the project dir (even if the directory of the current file is not the same as the project dir).
But if the current file is not from the current project, then building starts from the directory of the current file.

If I can find some spare moments at work I'll see if I can track the repro steps down further; spare moments are a precious commodity lately, though...
« Last Edit: August 13, 2008, 07:28:54 am by chrisant »

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Scratch that -- even files from the current project do not necessarily start the build from the project root.  I can't find a pattern yet for when they do or do not.

rwalsh26

  • New Community Member
  • Posts: 1
  • Hero Points: 0
I seem to have a similar problem to Ivan's.  I run a custom build command where I set up the Windows path environment variable.  However, when the command is done, the path variable seems to get set back to the value prior to running the command.  If I then run the custom command manually in the window, the path is set correctly.

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1249
  • Hero Points: 125
That's a different issue.  The command your running is passed to vsbuild executable, and it executes the command.  Any environment variable changes that happen there are local only to vsbuild.  If you need to set an environment variable workspace-wide you can set that through Workspace properties or Project properties.

As for the original problem, there has been some re-work for the upcoming 13.0.2 release, I'm hoping that will take care of some of these issues.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Confirmed that def_switchbuf_cd is involved:  when 1 builds generally start from the directory of the current file, but when 0 builds start from the project directory.

Note that just setting def_switchbuf_cd=0 isn't enough, you have to select the project to get it to change the working directory to the project directory.

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1249
  • Hero Points: 125
chrisant:  You have a reproducible case? I don't quite understand from your description what you've discovered.  What steps are involved exactly?  Is this a build of the active project or one of the other inactive projects in the workspace, and what files are open and relative to which project?  Any additional help you can provide would be great, and can try to roll a fix into 13.0.2.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
@Lee:
Yes, 100% reproducible.
Rephrasing:
1.  Set def_switchbuf_cd = 1.
2.  Have a workspace with multiple projects rooted at different subdirectories.
    e.g. project A = c:\src\proja, project B = c:\src\projb, project C = c:\src\projc.
3.  Set project A as the current project.
4.  Project A should have a custom Build tool with "Run from dir" == %rp.  I'm sorry I don't have time to put together a complete self contained repro, but the output in the Build toolbar shows what the cwd is, so regardless of what custom command line you have the Build tool execute, you should be able to observe that the cwd is incorrect.
5.  Project A should have "Working directory" set to "." in the Directories tab of the Project Properties dialog.
6.  Open some file c:\src\projc\foo\bar.cpp.
7.  EXIT SLICKEDIT and LAUNCH SLICKEDIT.  This seems to be important for getting it to be 100% reproducible.
8.  Verify that the current project is A and the current file is c:\src\projc\foo\bar.cpp (if you have to change the project or the current file then it may interfere with the reproducibility of these specific steps -- exit/launch/etc is not necessary for repro in general, but is part of the "surefire" steps I narrowed down).
9.  Choose Build|Build.
RESULT = The Build toolbar starts a build from c:\src\projc\foo.
EXPECTED = The Build toolbar should start the build from c:\src\proja since that is the %rp for project A.

How is "Working directory" used (the field in the Directories tab of the Project Properties dialog)?

Maybe I'm not configuring things correctly?  Maybe the documentation needs more detail about the "Working directory" field and the "Run from dir" field and what the various shortcuts (%rp, %rw, etc) mean in the two contexts, so we can understand how to set them to achieve our desired results?  I want a way to specify that "%rp" should be interpreted as the directory where the .vpj file is located -- I need a way for project paths/etc to be relative to the location of the .vpj file (absolute paths make it difficult to set up new machines because then I can't just copy .vpj files from another machine with a different parent tree structure).

@Ivan & others:  What do you have the "Working directory" field set to in the Directories tab of the Project Properties dialog?
« Last Edit: August 14, 2008, 10:04:22 pm by chrisant »

Ivan N. Zlatev

  • Community Member
  • Posts: 87
  • Hero Points: 5
@Ivan & others:  What do you have the "Working directory" field set to in the Directories tab of the Project Properties dialog?

Mine is just "." and I haven't ever touched it.

Lisa

  • Senior Community Member
  • Posts: 238
  • Hero Points: 23
  • User-friendly geek-speak translator extraordinaire
FWIW, we added docs for the working directory to a recent version... we need to add better index markers, but you can find it using the Help > Search, type in the search box (including the quotes): "the working directory". Now select the "Working with Files" entry - the working directory is documented there.

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1249
  • Hero Points: 125
%rw is equivalent to %rp in the case of Working Directory set to ".".   The Project Working Directory is set relative to the .vpj file,  Project properties won't let you set an absolute path for Working Directory.  %rp returns the absolute path to the vpj file and %rw returns the absolute directory of the Working directory relative to the project directory.

Going back to the original issue, it looks like that if the process buffer has not been created before the command to build is issued it obviously has to initialize the build window.  This is generating a switchbuf callback, and the current directory gets reset back to the current buffer.  The Run from Dir had already been set prior to the creation of the Build window, and did not anticipate that the directory would be changed.  This should only occur if process buffer has not been already created and your using def_switchbuf_cd, it should work fine after the first time initialization.  I will try to have this fixed for 13.0.2 release.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
@Lisa:  Yes, I had read the documentation, and it made sense.  I was just starting to wonder if the problem was user error instead of program error (in which case additional documentation to clear up the user error would be helpful -- but Lee confirmed it is a program error, so the docs are fine then :)).

@Lee:  Thanks++, that makes sense and explains why the behavior seemed intermittent.  It sounds simple enough to work around until 13.0.2 is available (caveat noted, that you'll try to have it fixed for 13.0.2, i.e. there's a chance it won't make it in):

Workaround: (when def_switchbuf_cd == 1)
1.  Start SlickEdit.
2.  Create process buffer via Ctrl+Shift+M (or Build|Show Build).
3.  Switch buffers so def_switchbuf_cd kicks in and changes the cwd.
4.  Now you can use Build|Build freely and it should set the cwd properly.