SlickEdit Product Discussion > SlickEdit®

Best approach for integrating SlickEdit with existing projects under Linux

(1/2) > >>

This request is largely platform-specific although I suppose it need not be. The main project I work on is actually a (disk) tree full of little subprojects which uses bakefile to generate the makefiles and GCC et al to compile/debug the code. Up till now I have been getting by just fine with Emacs and some custom scripts to do my work but took a chance on SlickEdit when I read that it has sharp subversion integration.
Not that I think it matters to the conversation but this is for Linux, running Ubuntu breezy on an AMD X2. We build everything with wxWidgets.

My question is what is the best way to integrate an existing complex tree such as this so that I can get the most out of SlickEdit. Currently I have created a workspace and for each subproject (as I need to work on them) I set up individual slickedit projects for each, starting with a blank project, I add the files manually and finally add 'make' in the Tools Compile and 'make clean && make' under Tools Build. A very laborious process. Is there a way to automate this?

As an extension, what about pre-existing subversion repos? Do I need to manually go through and configure each file or can it not use the existing .svn data?

Tks in advance...


When doing such 'Clone project' work I switched to copy and edit the <sub-project>.vpj file directly and add sub-projects to the <wkspace>.vpw manually.
Or imagine someone (above you) decides to change the filesystem structure of a project...
Thanks god, Slick provides search and replace at it 's best ;)

I'm much faster this way instead of mousing to death.


This is better but not really optimal; better looks like:
1. I say add project to workspace and point at a directory.
2. It finds all language-specific files and adds them to the project.
3. If a makefile is found, it too is added.

Optimal looks like:
I point at a root folder and slickedit walks the tree adding projects as it finds them with steps 2 and 3 above.

Ok - the 'Add Tree' support is there. At least for Project Props.
It adds everything you specify as file pattern. I didn't try the promising 'Add Wildcard' yet.
I afraid the 'Optimal' way is hard to do.
What's the criterion for dividing all the files somewhere in various directories into projects ? And which kind of project ?
Quite often projects are (unfortunately) not organized in a clear filesystem hierarchy.

Thought about it, but I afraid there is no easy way out :(


Well, the basic answer for parsing/doing project import could look like:

for each directory:
      If directory contains makefile (or other common project type):
              parse makefile, create project based on makefile with files listed within

Something like that. The actual files for the project are by default listed in the makefile directly or by a makefile rule.
A checkbox could denote automatically making subdirectory-based projects children of or dependent upon the parent directory project.

Bonus points would be awarded for the directory walking code to also pick up on .svn subfolders and autoconfigure SCM based on that.

Another aspect of this question though that I kind of expected someone to chime in with is this:
When creating a new vslick project, amongst other project types, I can create a GNU/C/C++ project and then I have some choices about who will manage the makefile. Since its not obvious to me (and I am working on a 'live' source tree) I have been creating my projects to add to my existing system using the blank project type and then GNU-izing it after the fact. Is the GNU/C/C++ project type only good for new projects or can it be used on an existing project w/o stepping all over the existing files?


[0] Message Index

[#] Next page

Go to full version