Custom build system integration

[Eric777]

Context:  I've been eyeing SlickEdit from afar for a very long time.  I've never downloaded the trial though because I never seem to have 2 consecutive weeks that I know I can devote to diving in before committing.  I thought maybe I could ask some questions on the forum about what's possible before starting the clock.

We use a custom build system that we like very much.  Does SlickEdit's build environment have the flexibility to plug in a custom build system?  I need it to be farther than just executing a custom make exe.  Ideally, it would allow me to do things like the following:

1) Allow me to respond to events like build/clean project, build/clean file, run/debug project.  In our current IDE, we have to hack this capability to intercept these events and prevent the IDE from responding on its own.

2) Allow me to furnish the set of errors/warnings/editorials with file/line# that we collected during the build (in our current IDE we just print the errors out in a format it can understand, which I'm guessing would work ok in SlickEdit too?)

3) Allow me to furnish compiler/preprocessor configuration per file to SlickEdit for correct code completion (i.e. c/cpp, exceptions & rtti on/off, initial preprocessor macros).  This is something we cannot integrate well into our current IDE, but maybe SlickEdit can do us better?

Also, can SlickEdit operate in a 'portable installation' mode (not installed via an installer?).  Our build system and all of the compilers/sdks we use exist in a repository of portable installations that we can take to any pc and build any of our projects without prior configuration on that pc, and with no residue left behind on that pc (other than deleted temp files).  I'd like an Editor/IDE that can work similarly and front that pipeline.  Our current IDE has too many hooks into the registry and system folders to work this way.

Note - I did run across this post: https://community.slickedit.com/index.php/topic,10136.0.html, which does speak to portably locating slickedit configuration files with an envvar or a cmd line option.  I'm wondering if there are any other roadblocks (i.e. perhaps licensing issues) that would prevent just file-copying SlickEdit into my tools repository on an external drive and and running it on any machine we plug into (provided of course that only a properly licensed user ever did so.)

Thanks!

-Eric

[Graeme]

I don't understand question 1.  What do you mean by "prevent the IDE from responding on its own".  Why do you need to "intercept" these events?  What do you do when you intercept them?

For question two, slick lets you dump your own error output into the build window or something like that.  You can write regular expressions to parse it so that "next error" can find the file / line number.

For question three, why do you need preprocessor configuration per file?  Slickedit builds a tag file from all your project files and it does limited preprocessor processing when it does this for performance reasons.  Any macros that you want slick to use a specific value for, you have to supply in a file usercpp.h  - or you can have a separate file for each workspace if you want.

For portable installation you should send this question to the sales department of slick, however I'm fairly sure you can put slick on a USB drive (or network drive) and run it without any installation on the target PC.  You probably need a license per machine that you run it on if different people are using those PCs.

[Eric777]

Regarding question 1, I want our own build system to be able to respond to the IDE commands for things like build project, build file, clean, etc.  I used the terminology "respond" to describe what I'd hope to do in an IDE that is configurable for alternate/custom build systems.  I used the terminology "intercept" and "prevent" to describe what we are forced to resort to in our current IDE which is not configurable for alternate build systems.  I am hoping to not have to intercept/steal/circumvent or otherwise work around SlickEdit's built-in build support.  I'm hoping I can configure it to allow me to do all build related processing.

For question 3, I'm hoping our build system can supply per-file configuration to SlickEdit (like preprocessor macros and important compiler settings like exceptions/rtti enable).  This is because the build system used, whether it's scons or jam or a custom one like ours, is what determines the macros and cpp flags used for compiling each source.  If an IDE cannot consume or accept this state directly from the build system being used, then correct code completion and linting would not be possible except by duplicating that state in a place the IDE can understand but that the build system doesn't itself use.  This is how we currently have to do it, but it's brittle and I'm wondering if SlickEdit might allow for a tighter integration with our build system.

[Graeme]

ok, well I'm still a bit confused so I'm gonna ask some more questions.

First, how many files in your biggest project?

Regarding linting, are you using pclint?  I'm guessing you want to lint a source file multiple times, once for each build configuration and your build tool knows the macro settings per file for each build configuration.  If this is correct then why don't you have SlickEdit pass the command, source file and selected build configuration to your build tool, which calls the lint tool and passes the output back to slickedit?

Regarding exceptions, sometimes you have them enabled and sometimes not.  Why does code completion or linting need to know whether exceptions are enabled or not?  Same question regarding RTTI.

Regarding "code completion"  - are you talking about SlickEdit's code completion?  Slick has what it calls "context tagging" as well as a pre-built tag database for the project which it uses for navigation as well as completion.  As you write code, slick continually parses the current source file so that code navigation and completion work within the current file even if there's no tag file or the tag file is out of date.  As mentioned before there is a global usercpp.h file that holds macro settings that you want slick to know about - or you can have a workspace specific file.  Out of the box, slickedit doesn't support having a different set of macro settings per source file, however, it may be possible to write a small amount of slick C code where you call the tagging engine for each file in turn and switch the content of usercpp.h before each call to the tagging engine.  Similarly for context tagging, you will need to switch the content of usercpp.h according to what the current source file and build configuration is  - this is possible but without trying it, I'm not sure how well it would work.  Can your build tool generate a source file with the macro settings needed for a particular source file and build configuration when asked and maybe also a file containing the lint options for that source file?
By the way, slickedit also has "selective display" which I find very useful when working with code that has lots of build targets.  You can hide all the code that isn't used for the currently selected build.

Regarding question one, building  - you can configure slick to execute any command you want for build, rebuild, compile etc.  Slick has this thing called vsbuild which I'm very hazy about - it knows how to make and build C/C++ and Java projects.  If you read this thread from 2009 https://community.slickedit.com/index.php/topic,4797.0.html it seems to imply that when you have a totally external build, you can still call the external tool via vsbuild and the output coming back from the build tool will be processed by vsbuild and used to generate entries in the message list window.  The help file doesn't say much about vsbuild but the mentioned thread suggests you use the "-command" switch to call jam.

Code: [Select]

"C:\sefolder\vsbuild" -signal 9009 -command c:\jam\jam -j4 -CC:\projectfolder\ -sPLATFORM=win32 -sCONFIGTYPE=debug
The "-command" switch seems to be undocumented, same with the -signal switch, so I really don't know how people end up using these things.

Out of the box, the default rebuild command for a project is this

Code: [Select]

"%(VSLICKBIN1)vsbuild" rebuild "%w" "%r"Slick has a long list of "%" options that you can use in a project tool command, one of which is %m which lets you run a slick C macro which can do whatever you want  - including pass back some options to pass to the build tool.

[Is there any way to configure this forum not to log you out after a certain time - if I hadn't made a copy of what I wrote above, it would have disappeared].

[Eric777]

I don't think any of our projects would be too big to digest for any reasonable IDE, so I'm really not worried about that with SlickEdit.  Two of our larger projects have around 1800 and 2700 source files, but most of our projects are much much smaller than even that.  We do have hundreds of small projects with a dozen to a hundred source files each, and I personally will often have a dozen or more IDE instances open across these projects, so finding an IDE that doesn't help itself to hundreds of megs per instance and that launches/quits/responds quickly is a big deal to me.  I believe I've read that SlickEdit is quite good in this area.

We do not use pc-lint.  Also, I didn't mean to confuse with the term "code completion", and I absolutely am only asking about SlickEdit's implementation.  By "code completion", I simply mean the IDE's ability to parse our sources and provide correct context information in the editor while coding (i.e. highlighting errors, displaying function arguments, structure members, etc)

Whether exceptions/rtti are enabled most definitely effects what syntax is legal and what isn't.  If exceptions are off, I would expect an IDE to visually flag all uses of try/catch/throw (i.e. underline red in the editor or similar).  If rtti is off, I would expect any code that downcasts with dynamic_cast to be flagged.  However, don't get too hung up on these two compiler features - I cited them simply to communicate that preprocessor state isn't the only thing I hope to supply to an IDE for correct interpretation of our sources.  While correct preprocessor state is the most important thing to me for code completion, there are c++ language features too that may be of interest to the implementation (i.e. exceptions/rtti enabled, availability of various c++11/14/17 language features).

Regarding usercpp.h, I had at first thought you were suggesting I just duplicate my preprocessor settings there and manually keep them in sync with the build system in all of our projects.  Your suggestion of auto-generating that file is great, and yes I can absolutely make our build system spit this out.  I'd hope to supply preprocessor/compiler state per-file, but differences between files in the same project are few enough that I could probably live without this if everything else was super tight.

Thanks for the link to that post.  If I am reading that post and your comments correctly, it sounds like vsbuild is exactly the choke point I'd want for responding to build events and sending back output to the IDE.  That tip will definitely take many hours off of my trial period scramble!  Just gotta find a couple good weeks...