SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: timur on June 22, 2007, 08:47:21 pm

Title: Per-project C Preprocessing for tag files?
Post by: timur on June 22, 2007, 08:47:21 pm
I notice that when I specify a C macro for tag file pre-processing (Tools->Tag Files...->Options...->C Preprocessing...), any C macros I add are put into ~/slickedit/11.0.2/unxcpp.h, which means they affect all projects.  I don't know why Slickedit does this, because it's pretty stupid.  Why would the same pre-processing macro apply to all projects?

Anyway, is there a way to fix this?  I want to specify a list of macros only for a particular project.

(More specifically, I'm working on multiple Linux kernel source trees, one per project.  I want Slickedit to use the include/linux/autoconf.h file if it exists - the format is the same as unxcpp.h).
Title: Re: Per-project C Preprocessing for tag files?
Post by: cappy2112 on June 23, 2007, 01:37:22 am
Anyway, is there a way to fix this?  I want to specify a list of macros only for a particular project.

That is bad.

I got around other problems with Slick's problem with the preprocessor by scanning the header files with an external program that I wrote, and generating a file specifying the symbols and their definitions.
I then load this into Slick and pass it to the preprocess() function.
Our list of definitions is so big, I could not paste it into Slick's edit box on the Selective Display dialog.

This workaround has been working pretty well.
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on June 23, 2007, 12:59:17 pm
@timur: You mean per workspace, right ? There is only a workspace tagfile which would be affected.
However, I fully agree. There should be a workspace property/option to explicitely specify a '<workspace>.vph'.
It would be nice if SE would ask the user if it should be derived (read: copied) from another workspace/global usercpp.h if it's not existing.
If it's not specified just the global one is used. This would be a compatible solution for all others who don't need this.

I think this would be a great improvement for multi-platform (multi-OS, multi-HW) development.
I wonder how the SlickTeam manages their multi-OS development ... assumingly there are no evil #ifdef's and a well designed OS-abstraction layer, right ;)

HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: cappy2112 on June 23, 2007, 05:10:26 pm
@timur: You mean per workspace, right ? There is only a workspace tagfile which would be affected.

No. I am scanning the .H files in the project to pull out the defines myself. Slick has an option to do this, but for some reason it doesn't do it right with our project

Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on June 23, 2007, 05:19:05 pm
@cappy2112: Your per project preprocessing might be useful for some feautres as selective display and such, but tagging is per workspace.
Hence all tagfile related features (e.g. Class Browser, Find Symbol TBs) can be setup/adjusted per workspace only.

HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: cappy2112 on June 23, 2007, 11:05:30 pm
@cappy2112: Your per project preprocessing might be useful for some feautres as selective display and such, but tagging is per workspace.
Hence all tagfile related features (e.g. Class Browser, Find Symbol TBs) can be setup/adjusted per workspace only.

HS2

This is really bad. I've got to find the features request forum.
I have multiple projects in the same workspace (like many people, I'd expect).

What's the sense of only having one tagfile, and have to wast time re-scanning tags when switching between projects?
This is one thing that Codewright did right- per-project tagfiles!
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on June 23, 2007, 11:46:12 pm
Well, it depends...
I'd propose to check the 'Help->Workspaces and Projects' and also these 2 postings to get an idea how and why it's organized as it is.
http://community.slickedit.com/index.php?topic=855.msg3726#msg3726 (http://community.slickedit.com/index.php?topic=855.msg3726#msg3726)
http://community.slickedit.com/index.php?topic=1538.msg6518#msg6518 (http://community.slickedit.com/index.php?topic=1538.msg6518#msg6518)
Please take into account that this design is existing and proven since a long time before issueing a feature req. with such a major impact.
I'm sure there are a number of good reasons for it, although I'm not aware of all of them of course.
Hey, maybe the SlickTeam has already started a redesign of it - who knows... ;)

Just my 2ct,
HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: Kohei on June 24, 2007, 03:16:20 am
I also support the idea of per-workspace C-preprocessing list.  That would also make my life tremendously easier.

What would also help is a little dialog box with a list of discovered preprocessing macros during the first workspace tagging.  Then the user can pick and choose (or select all) which preprocessing macros to define in the second round of workspace tagging.  I ask this because right now, I define one preprocessing macro at a time, every time the tagging behavior is odd, which is usually caused by a (rather silly) use of preprocessing.  But in a project with an unfortunately large number of preprocessing macros, this can be very time-consuming, because each time I add a new preprocessing define, I have to re-tag the whole workspace.

So, here is my vote for adding a per-workspace C-preprocessing list, in addition to the global list of C-preprocessing.
Title: Re: Per-project C Preprocessing for tag files?
Post by: timur on June 25, 2007, 07:00:44 pm
You mean per workspace, right ? There is only a workspace tagfile which would be affected.

Yes.  I always have one project per workspace, so I use the terms interchangeably.

Quote
I think this would be a great improvement for multi-platform (multi-OS, multi-HW) development.
I wonder how the SlickTeam manages their multi-OS development ... assumingly there are no evil #ifdef's and a well designed OS-abstraction layer, right ;)

I also wonder sometimes if the SlickEdit developers use their own product.
Title: Re: Per-project C Preprocessing for tag files?
Post by: Kohei on June 26, 2007, 03:05:05 pm
Quote
I also wonder sometimes if the SlickEdit developers use their own product.

Of course, they do!  What makes you think otherwise, I wonder.
Title: Re: Per-project C Preprocessing for tag files?
Post by: jimlangrunner on June 26, 2007, 06:11:18 pm
I also wonder sometimes if the SlickEdit developers use their own product.

While I cannot speak for the team, I can believe that they use it.

http://blog.slickedit.com/2007/06/how-to-design-software-with-bad-requirements/

The trick is that there are so many ways to do something (anything) that there is no way anyone could possibly try all the options.  Not to mention the languages, platforms, etc. that Slick supports.  Then the test cases and tests to make sure the product stays fixed.  It's incredible.   8) 

(and this is the point where I usually just cancel the post, but not this time.  These folks are cool)
Title: Re: Per-project C Preprocessing for tag files?
Post by: ScottW, VP of Dev on June 26, 2007, 07:40:37 pm
Thanks, Jim. You said most of what I was going to post on this subject. But let me reiterate just a bit.

You bet we use SlickEdit to write our own code! Most of the team is so hooked on SlickEdit that they'd switch careers before they'd use another editor. The problem we hit is that we use SlickEdit to write SlickEdit...and that consumes almost all of our time. We have a single workspace in which we spend the overwhealming majority of our time.

Sure, we have projects we've created for testing, but these can never rival the complexity and diversity of real-world projects. Even if the code base is large, we won't mirror the many possible ways to structure the projects, do builds, interact with source control, etc. So problems you hit frequently, which seem like a no-brainer to fix, are likely to be use cases we just don't run into, like #defines being shared across workspaces.

So we rely on our customers to help us. When you run across something in SlickEdit that doesn't support your workflow, please report it. The best way is to select Help > Contact Product Support from the main menu. This will take you to a web page where you can describe the problem you encountered. Even if you aren't on Maintenance and Support, you can use this interface to report bugs  or suggest product improvements. You can also send feature requests to features@slickedit.com.

When you describe the problem, please include information on why this is important to fix, the impact the fix has on your workflow. This information may seem obvious to you, but it's a real help to me when I'm looking through Change Requests trying to determine priorities.

We can't fix every problem in any given release, but we do make an effort to address the issues that cause the greatest difficulty for our customers. If you have a change that you've requested and it hasn't been implemented, feel free to email me at swestfall@slickedit.com.

--Scott
Title: Re: Per-project C Preprocessing for tag files?
Post by: Graeme on August 20, 2008, 03:18:26 am
I want to add a vote for per workspace pre-processing lists, especially because when you have conditional compilation with shared source files, you have to change the pre-processing lists every time you switch workspaces, or else live with inaccurate tag files  - which is normally what I do, but I'd like not to.  Actually, even when you don't switch workspaces you might want to switch pre-procesisng lists quickly and easily and re-tag so I think more than just per workspace pre-processing lists is needed.

It seems you can achieve this by switching the content of usercpp.h in the config folder and rebuilding the tag file - maybe I'll get round to automating this sometime.

Graeme
Title: Re: Per-project C Preprocessing for tag files?
Post by: Graeme on August 20, 2008, 03:52:33 am
Just discovered the user manual says you can modify usercpp.h directly.

Tried this and it seems to work - so now I switch USERCPP value to switch preprocessing options, which solves the problem quite well.

(Now I wonder whether I need to fiddle with syscpp.h in installation folder to get rid of several thousand #defines I don't need ... )

Graeme


<usercpp.h>
Code: [Select]
#define USERCPP 2

#if USERCPP == 1

#undef BUILD2
#define BUILD1

#else

#undef BUILD1
#define BUILD2

#endif

Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on August 20, 2008, 11:25:41 am
Good idea to use conditional parts in usercpp.h ! HP++
That seems to be a reasonable workaround although the direct editing of this file is a bit clumsy...
HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: Graeme on August 20, 2008, 12:15:38 pm
Good idea to use conditional parts in usercpp.h ! HP++
That seems to be a reasonable workaround although the direct editing of this file is a bit clumsy...
HS2

I'm not sure if it's officially supported to do this but it's working fine for me.  Yeah it's perhaps a bit clumsy but I suspect it's more powerful than a GUI could be  - I don't know how you would generalize what I would want into a GUI.  Editing usercpp also makes it easier to find things and see what the current defines are than a GUI would be.  Maybe the exisitng GUI could be improved by separating usercpp from syscpp stuff but it's not a problem any more.  I guess I could also write a macro that switched usercpp settings automatically when I switched projects - or maybe usercpp could allow interrogation of things like current project/ current workspace etc- or access "defines" that are set in project properties.  You wouldn't need to rebuild the tag file every time you switched workspaces, even though usercpp is technically changing when the workspace changes.

Graeme
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on August 20, 2008, 02:18:32 pm
The idea is to have a <workspace>cpp.h corresponding to a <workspace> and it's associated tagfile and e.g. to use the global 'usercpp.h' as fallback if the user doesn't specify a specific one.
This is basically the same as using ONE conditional usercpp.h but it 'd allow to use the GUI-based configuration as usual.
HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: Phil Barila on August 20, 2008, 04:20:29 pm
I'd like to see SlickEdit take the workspace tag config much further.  I'd like to be able to limit the workspace to a subset of the compiler tag files, so if I have a workspace that builds with Cygwin, I can exclude the Visual Studio tag files entirely.  Taking that thought a little further, I'd like to make that a part of the build configs in the project, so I can select different configs and have them select tagfiles appropriately.  The default for all of that would be all tagfiles, of course, you have to set the option to limit things.  That would really enhance my particular workflow.
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on August 20, 2008, 06:55:29 pm
@Phil: AFAIK the compiler tagfile is already automagically selected according to the per project compiler.
Hmm - this could cause minor problems when editing a (workspace) file which belongs to another project with a different compiler setup ???
HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: Phil Barila on August 20, 2008, 07:29:57 pm
@Phil: AFAIK the compiler tagfile is already automagically selected according to the per project compiler.
Hmm - this could cause minor problems when editing a (workspace) file which belongs to another project with a different compiler setup ???
HS2
I've not seen that behavior.  I always get all the tags that match.  I'd love to know how to limit that.
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on August 20, 2008, 08:01:36 pm
This works for me (SE >= v12.0.3) with the 'C Compiler Configuration Tag Files' and the appr. compiler set for the current project.
HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: chrisant on August 20, 2008, 09:49:31 pm
I get the same problem as Phil gets, but not consistently.  I haven't reported it to support yet because I still don't understand what determines whether I'll see tags from all compiler tagfiles in existence, versus only the compiler tagfile for the current project/compiler configuration.  In 12.0.3, 13.0.0, and 13.0.1 often when I try to look up symbols it will show hits from 3 different C compilers plus C# tags too (I don't use C# anywhere).  I need to find time to nail down the repro steps so I can post a well-formed actionable report.
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on August 20, 2008, 10:50:17 pm
Strange - this (http://jcooney.net/images/articles/worksonmymachine_logo_small.png) ;)

I could imagine that e.g. when using Find Symbol TB with 'Look in' set to anything different to 'Use Context Tagging ®' leads to undesired results. But AFAIK 'push-tag' is fixed to 'Context Tagging ®'...
HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on August 20, 2008, 11:12:06 pm
Sorry - forgot to mention that I still refer to v12.0.3 r35... HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: chrisant on August 21, 2008, 01:19:44 am
For real:  :(

See attached screen shots.
I have 3 C compilers:  Windows Mobile, VS 2005, CodeWarrior for Palm OS.

Symbols for all 3 show up.
The screen shots show an example of "strcmp" showing up from the WM and VS2K5 compilers.
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on August 21, 2008, 10:04:01 am
Ok - I've double checked it with v12.0.3 and I get the appropriate tag hits for a VS2005 solution and a GNU Project (C/C++) with a specific compiler setup (it's not the default cygwin compiler).
I've also used 'strcmp' and tried push-tag and Find Symbol TB. Sorry, but it's working fine for me. Seems that's a v13.0.x problem.
HS2
Title: Re: Per-project C Preprocessing for tag files?
Post by: Graeme on September 04, 2008, 08:40:45 pm
Good idea to use conditional parts in usercpp.h ! HP++
That seems to be a reasonable workaround although the direct editing of this file is a bit clumsy...
HS2

oops, I think using conditional compilation in usercpp.h doesn't work after all.  Not sure why I thought it did.  Still, commenting out stuff does work as long as you don't do a save in the GUI dialog.  (I guess Dennis didn't read this thread yet!).  Oh well, it's not that hard to automate switching usercpp.h if anyone really wants to.

Graeme
Title: Re: Per-project C Preprocessing for tag files?
Post by: hs2 on September 04, 2008, 09:18:10 pm
That's a pitty... (didn't tried it yet).
Right, you shouldn't use the GUI after manually changing usercpp.h. It's alpha sorted on GUI-save etc.
And yes, messing around with per workspace usercpp.h copies is a workaround on my long term todo list.
But fortunately pressure wasn't high enough to start with up to now...
HS2