Author Topic: Best approach for integrating SlickEdit with existing projects under Linux  (Read 18243 times)

jeffcobb

  • Community Member
  • Posts: 23
  • Hero Points: 1
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...

Jeff

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
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.

HS2

jeffcobb

  • Community Member
  • Posts: 23
  • Hero Points: 1
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.


hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
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 :(

HS2

jeffcobb

  • Community Member
  • Posts: 23
  • Hero Points: 1
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?

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
You'll easily see, that your proposal seems ok for a *very* specific (your) use-case.
(Even parsing a customized makefile can be hard enough.)
That's the problem. There are zillions of ways people organize their projects using a variety of build tools and version control systems.
I (still) afraid that there is no 'generic' way of 'creating a workspace from source'...

HS2

jbezem

  • Community Member
  • Posts: 87
  • Hero Points: 8
for each directory:
      If directory contains makefile (or other common project type):
              parse makefile, create project based on makefile with files listed within

That would kill my personally favourite structure, since my makefiles do not include any file lists. Instead, they include a master makefile, which in turn implicitly uses GNU-make pattern rules in addition to $(wildcard...) to automatically find me all C/C++/Java/... files, and turn them into an executable, static/dynamic library, or whatever.
No chance for any tool to guess that from the recursive makefiles embedded in my source tree.
And my version control system may contain many more files, since occasionally my makefile specifies files and/or directories to be _skipped_, not to be included...

Sorry, but one size doesn't always fit all :-(

FWIW,

Johan

jeffcobb

  • Community Member
  • Posts: 23
  • Hero Points: 1
Everyone who is responding:
Thanks for your input.

First, while both of you have a point about my solutions applicability to your personal situations, that wasn't what I was trying to express. What I was trying to show is some general logic that would solve my problem; the specifics were only a suggested method, not any statement of a definitive solution; *that* I was leaving up to the brighter minds at SlickEdit <grin>. Now as for jbezem's concerns about file specifics not i the makefiles, that is where I was referring to analysis of the makefile rules that sort out which files. The makefile in one fashion or another sorts out the source code based on the file system and data/logic contained in the makefile. This logic could be parsed and followed to make a file list for a project....and as for this solution simply being specific to me, yep it is because that is the world I worlk and live in so this is how Slickedit could excel *for me*....

heedless

  • Community Member
  • Posts: 24
  • Hero Points: 1
I work for a very large organization with a huge code-base.
Our main platform is IRIX and we use custom build tools and scripts.
They look like some sort of extended makefiles with a slightly different format, structure and keywords (but the concept is the same).

When I pushed vslick into our organization i had to write a perl script that recursed into our source tree and parsed each "makefile", then generated appropriate vslick projects and workspace files.

(I created xml templates of vslick projects and just filled them with the files I found inside each makefile)

My script is very specific for our code base though.

However, I do want to point out some of the problems with this approach:
1. Makefiles and the likes, generally do not list all source files - particularly header files.
They generaly do list all C/C++ Source files (which in turn use include statements to pull their required headers).
So a better solution would also have to parse the C/C++ source files and add files found there to the project list.

Another problem would be,
2. That you'll also have to keep some sort of dictionary for PATH variables.
for instance, our "makefiles" include other makefiles which define variables who are used as paths.
like: IMAGING_LIBRARY/main.cc
where IMAGING_LIBRARY can be defined under a different makefile (from the currently parsed) like:
IMAGING_LIBRARY=PLAT/img
and in some other file you'd find:
PLAT = /src/plat

I had to parse the makefiles, gather symbols, create a dictionary (a hash table is the most suited) and then dereference the appropriate paths.


It takes about a week and a half to write a rudimentary version and another month to polish it and fix bugs.

This approach is suitable if your organization is willing to dedicate 1 person for approximately 1 month for this task.