DOS compatible paths in build tool

[LBCEi]

I am evaluating SlickEdit and am quite impressed so far.  I have been a user of CodeWright for many years and am thinking of moving to a new editor/environment which is supported and, hopefully, will continue to improve over time.

I've been relatively successful in getting the things I used to do in CodeWright set up but one problem I'm having has eluded all of my attempts to fix/understand it.

Here's the background:

I have a embedded system (unmanned aircraft autopilot) project with source code in both a main directory and a subdirectory.  The main directory contains the hardware specific stuff like the system boot code, BIT tests, real-time task scheduler, I/O drivers (hardware access routines), etc. The subdirectory contains the "flight" code that actually does flight control, guidance, etc.  This is kept separate because it is also used in simulation builds which do not run on the real embedded hardware.  This way we can check out the "flight code" (the stuff in the subdirectory) from version control for the simulation builds and only need to get the "main" directory stuff when building for the actual target hardware.

The tools that we use to build the code for installation in the hardware builds the entire code base (main and subdirectory) as a single build.  The cross-compiler and linker are quite old and only understand DOS compatible (8.3) paths and file names.  My make file accommodates this by including the DOS compatible relative path for each of the files that are in the GQM_Flight_Code subdirectory (this 8.3 path is ./GQM_Fl~1).  For example, the compile command line generated by the make file for a non-flight (main directory) C source file looks like:

Code: [Select]

cpl -I.\GQM_Fl~1 IO_Init.c
and the command line for a flight-code file looks like:

Code: [Select]

cpl -I.\GQM_Fl~1 .\GQM_Fl~1\Guidance.c
I have a few questions/issues related to this situation:

Is there a escape sequence (similar to %p) that would give the DOS compatible relative path to the current file?  This would allow me to invoke my compiler on a selected file directly (without doing a build using my make file which has the 8.3 relative path hard-coded into it)? 

I was able to set up an error parser for my compiler and it finds the errors in the code.  The problem is that, since the compiler is given the 8.3 path to the files that are in the subdirectory the error message includes this path along with the file name.  When I goto an error (next error, ctrl-shift-down, etc.), the editor actually opens a new window using that 8.3 path and doesn't recognize that this is the same as the file that uses the long version of the path.   Here is a sample error message:

Code: [Select]

E ".\GQM_Fl~1\Descent.c",L105/C5(#222): speed_of_soun
|    Identifier is undeclared; assuming `speed_of_sound' instead.
For instance, if I do a build that has an error in the Guidance.c function (in the flight code subdirectory), the editor opens a window to "C:\Documents and ...\GP_Software\GQM_Fl~1\Guidance.c" to show the occurrence of the error.  This happens even if I already have that file open in a window as "C:\Documents and ...\GP_Software\GQM_Flight_Code\Guidance.c".

If I fix the error in the new window and save, I get prompted with "Another application has modified the file:  C:\Documents and ...\GP_Software\GQM_Flight_Code\Guidance.c.  Do you wish to reload it" -- this actually only happens if I switch focus away from SlickEdit and then back.  The editor doesn't recognize that these two windows are really the same file.

This also seems to be affecting the "Save Workspace Files" option on the Project Properties, Tools tab.  The editor doesn't save edits to any of the files in the subdirectory when this option is active and I run a build.  (This may actually be a separate problem.) If I switch the option to List Modified files I do get a pop-up saying that that file was modified and allowing me to save it.  I'd rather have the file automatically saved but I don't necessarily want all open files saved (just the ones that are in the project workspace and affect the build).  I think this is the difference between the Save All Files and Save Workspace Files options, is that correct?

One more question -- There is an article entitled "SlickEdit Offers Help to All CodeWright Orphans" that is referenced in a forum post.  The URL is "http://www.slickedit.com/content/view/435/93/".  This page indicates that there is a utility for importing CodeWright projects into SlickEdit and provides a link to download it.  When I click the link I get a browser opened to a page that says "You are not logged in to the site, please use the login form on the right side of this page to login."  I registered for a SlickEdit.com account and logged in but I still get the same response.  Is this link broken?

I had wondered about the Project, Open Other Workspace, Convert Codewright Workspace menu item before I found the above referenced page (since the menu item sounded useful but didn't seem to do anything) and would like to try this utility if it still exists.  I'm also wondering why there is a menu item for it if the utility isn't included with the editor installation.

Thank you
Les

[Matthew]

The macro that does the project conversion didn't ship with the SlickEdit 2007 (12.0.0) installer. Our bad. It was a new file and the install builds didn't pick it up. Send an e-mail to support and they should be able to email you a copy that you can drop into your installation's macros directory.

As far as the custom compiler error parsing, can you possibly pass the full path, with quotes (and not the 8.3 format) to your compiler, and will it report the full quoted path? That's the easiest way for the editor to resolve and load an error line file name.

Another option would be to change your regular expression, so that just the file name and extension are parsed. So instead of the "{#0:p}" that most expressions use, could you instead try something like this a this as the expression:
 E:b"?#\\{#0:p}",L{#1:d#}/C{#2:d+}?*\::b{#3?#}$
What this would do is pick up just the filename.ext, and not the whole leading relative path.

[LBCEi]

Thanks for your response.

Re: the conversion utility.  I'll send a message to support about this.

Re: the path issue.  I can't use a non-DOS format path, relative or absolute, because the compiler doesn't support the non-DOS format.  If I pass only the filename (no path) the compiler won't find the file since it is a subdirectory of the project working directory.  The build compiles the files in this subdirectory and the object files are placed in the main directory for linking.

Is there a reason that the editor can't recognize that it doesn't need to open another window for the file using the 8.3 directory name?  In other words the key issue (as I see it) is the fact that, as I said in my original post: "The editor doesn't recognize that these two windows are really the same file."

Apparently the answer to "Is there a escape sequence (similar to %p) that would give the DOS compatible relative path to the current file?" is no.  Is that something that I can add with a macro or environment variable or some other means?

Also, do you have any ideas on the Save Workspace Files issue (repeated here)?

This also seems to be affecting the "Save Workspace Files" option on the Project Properties, Tools tab.  The editor doesn't save edits to any of the files in the subdirectory when this option is active and I run a build.  (This may actually be a separate problem.) If I switch the option to List Modified files I do get a pop-up saying that that file was modified and allowing me to save it.  I'd rather have the file automatically saved but I don't necessarily want all open files saved (just the ones that are in the project workspace and affect the build).  I think this is the difference between the Save All Files and Save Workspace Files options, is that correct?

Regards
Les

[Matthew]

The problem with the editor re-opening a file that it already has open (due to the slightly different path name) is a separate issue that I don't have a workaround for. That's why I suggested you try the expression that only picks out filename.ext. SlickEdit may be able to resolve that "filename.ext" is the same as "C:\My\Already\Open\filename.ext".

And no, we don't have a pre-canned expression that will give you a relative path in 8.3 format. However, you could create your own macro in Slick-C that would take the current active file path, convert it into 8.3 format, and then call your compiler.

Here's a quick starter sample macro

Code: [Select]

_command les_compile() name_info(','VSARG2_MACRO|VSARG2_MARK|VSARG2_REQUIRES_MDI_EDITORCTL)
{
   // File path of current active document
   _str filePath = p_buf_name;
   // Do what you need to construct the commandline
   _str relPath = relative(filePath);
   _str commandline = "cpl -I " :+ relPath;
   // This will execute the command and print results
   // to the build window
   concur_command(commandline);
}After creating your macro, you can either invoke it from the SlickEdit commandline, or set it up as a build tool in your projects. You'll use the "Command is Slick-C Macro" checkbox when setting up the build tool.

[LBCEi]

Thanks for the suggestions.

I've got all of the issues mentioned in this thread resolved. 

Matthew's suggestion for using a different regexp parsing string fixed the error message parsing (I modified it to match the second line of the error message as well).  The regexp string I settled on was:

Code: [Select]

E:b"?#\\{#0:p}",L{#1:d#}/C{#2:d#}?*\::b{#3(?#\n*?#)}$I guess I was thinking that, since I needed the relative path for the compiler, I should try to capture it with the error parser as well.  Matching only the filename and extension allowed the error parser and editor to associate the error with the project file correctly.

I also adapted the suggestion of using a macro to build up the command line for compiling a single selected file.  FWIW, here is the macro I am using:

Code: [Select]

#include "slick.sh"

/* $Revision: $  $Date: $  $Author: $ */

/* Invoke the MetaWare High-C compiler (using the cpl.bat script) on the
   selected file. This macro generates the DOS (8.3) compatible relative path for
   the selected file and passes it to the cpl.bat script so the compiler can
   find the file */

_command void HighC_compile_selected_with_DOS_relative_path() name_info(','VSARG2_MACRO|VSARG2_MARK|VSARG2_REQUIRES_MDI_EDITORCTL)
{
   _str commandline = '';

   /* File path of current active document */
   _str filePath = p_buf_name;

   /* Construct the command line */

   _str file = strip_filename(filePath, 'P');

   _str relPath = relative(filePath);

   if (relPath == file) /* file is not in the flight code subdirectory */
      {
      /* for now use a hardcoded cpl.bat parameter 1 (flight code dir) */
      commandline = 'cpl .\GQM_Fl~1 ' :+ file;
      }
   else                 /* file is in the flight code subdirectory */
      {
      /* use actual subdirectory name and convert to 8.3 format */
      _str relPathDOS = substr(relPath, 1, 6) :+ "~1";
      commandline = 'cpl ' :+ '.\' :+ relPathDOS :+ ' ' relPathDOS :+ '\' :+ file;
      }

   /* Execute the command and print results to the build window */
   concur_command(commandline);
   set_error_markers();  /* activate the error markers */
}

Thanks again for the help.

[LBCEi]

FWIW -- a minor tweak to the error parser regexp:  E:b"?*\\*{#0:f}",L{#1:d#}/C{#2:d#}?*\::b{#3(?#\n*?#)}$