How To Setup Compile Tool in v12.0.1

[mychong]

Downloaded and installed SE v12.0.1. Old tricks that get around the "error-markers no show" problem apparently ceased to work. Could someone kindly help me to setup the compile tool under v12.0.1? Details needed.

OS: Linux Fedora Code 1 (2.4.22-1.2115.nptl)
Compile tool: bcc (a bash script that calls Kylix C++ compiler to compile the current file)

Command line: ~/bin/bcc %f
Run from dir: %p
[X] Capture output                              Menu caption: &Compile
[X] Output to build window                  [  ] Build first (greyed out, cannot select)
[X] Clear build windows                      [  ] Command is Slick-C(R) macro
                                                        [  ] Verbose output (greyed out, cannot select)
Save current file                                [  ] Beep on completion (greyed out, cannot select)
Always show on menu                       [  ] Run in an X terminal


TIA,
M.Y.

[Lee]

We were not able to address the issue error-markers not working for Compile commands in 12.0.1 release.  What workarounds were you using in 12.0.0 release that do not work in the 12.0.1 release?  If you provide details on what you were doing, I will to investigate the problem, but it was certainly not our intention to make the problem worse.

[hs2]

@Lee: I think mychong is using this workaround. http://community.slickedit.com/index.php?topic=1391.msg5976#msg5976.
I really hope that this trick (calling macro commands form external script) is still supported.
Can you confirm this ? (No - I didn't update yet.)

HS2

[mychong]

@Lee: hs2 is right. I was using this trick ("bcc.bash" as provided by him) happily until I downloaded and installed v12.0.1. Look like I have 2 choices at this moment:
 i) re-install v12.0.0
ii) Wait for someone to come out with another brilliant trick.

@hs2: thanks again for your help. You are always there when someone is in trouble (with SE).

BTW, I noticed that the other problem that I complaint - half-working mouse under Linux - is already fixed. Thanks.

[hs2]

H..ll, the markers weren't working for me too
Found that it's related to a global var which isn't init'd properly or still has an old value, which is now invalid.
Maybe it's caused by just updating Slick ?
This forces a reinit of the g.var:
Edit: I attach a small module to be just loaded and unloaded after executing error-markers-sane.

Run it once on cmdline. This should be enough. You can delete it afterwards.

Have fun,

HS2

[hs2]

Sorry,

the macro doesn't solve the problem - it reappears when restarting SE

This patch should help (works for me):
error.e - definit() [line 372]:

Code: [Select]

   _pic_error = 0;

HS2

[mychong]

@hs2: Not sure where I missed. I inserted the said line in "error.e" (as shown below) as suggested, but the error marker still refused to show.

definit()
{
   _error_re = '';
   _pic_error = 0;                 <-- inserted this line
   gpictype_error = 0;
   allExpressions._makeempty();
   extExpressions._makeempty();
   exclusionExpressions._makeempty();
}

p.s. I only tested this under Windows XP, with Borland C++ 5.5.1 compiler.

[mychong]

I would like to hear from SlickEdit Team Members how they are going to fix this problem.  It was working fine with SE v11.0.2.

M.Y.

[Lee]

Please do not make any modifications or reload the shipped version of error.e.  This module should not be unlinked or reloaded.  Please load the attached workaround for 12.0.1 release.  This workaround only address the issue of error markers not appearing in 12.0.1 release and only where they were appearing in the 12.0.0 release.

The current status of the error marking feature is that are currently only available for Build and Rebuild project commands and but only when using vsbuild for the build system (which is usually automatic for gcc projects and java projects).  It is not automatically available for the Compile command or any custom build commands, and it is also not automatically available for building associated projects (Visual Studio for example) without tweaking or workarounds.  It has been problematic making it work for all of the use cases available to SlickEdit users.  In future releases, we are looking into making it uniformly available for all project commands. 

As always, we appreciate your feedback and your interest in this feature.

[mychong]

@Lee: I tried the workaround, and it works (if and only if I used this with the customized batch file from hs2, which call 'set-error-markers' after executing the compile tool). Thanks.

Just an idea - Would it be possible for the Compile Tool to have an option to run any "Post Compile Commands" (something similar to Build)? In this way, we may be able to call the 'set-error-markers' macro at the end of compilation.

@hs2: I finally figured out how to use your patch. This works as well. Thanks.

M.Y.

[hs2]

I agree with mychong. An optional and synchronized post-<any build tool> command (set) maybe similar to the 'Project->Open' feature would be fine.
Curr. there is no way to wait for the end/completion of a 'concur_command'. Would be great if this could be added to the API and I think it's anyway needed to support the post-<any build tool> command. Or a hint howto do this using 'vsbuild' would be appreciated.

@Lee: Could you please explain why 'This module should not be unlinked or reloaded.' ?
Would be good to know...

Thanks,
HS2

[Lee]

Those ideas would certainly add to the power and flexibility of the SlickEdit build system.  I will make sure they are noted and added to the feature tracker for consideration. 

hs2:  As for my previous statement, I may have been a *tad* overly cautious with my warning (at least I didn't type it all CAPS).   In the previous release cycle, I had a number of issues while working on that module, which required a complete rebuild of the state file to clear it up (or starting a new config completely).   I've just tested it in the 12.0.1 release, I haven't been able to reproduce the issue.  Whatever problems were of my own doing, so I think it safe to continue working on it.

[hs2]

OK - thanks Lee. I already recognized some unexpected (for me) interferences / 'crosstalk' between modules when (re-)loading them in arbitrary order while migrating some indispensable customizations.
Hence I'm extremely careful when dealing w/ product sources.

HS2