Author Topic: Per-project C Preprocessing for tag files?  (Read 18960 times)

timur

  • Senior Community Member
  • Posts: 180
  • Hero Points: 3
Per-project C Preprocessing for tag files?
« 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).

cappy2112

  • Community Member
  • Posts: 91
  • Hero Points: 0
Re: Per-project C Preprocessing for tag files?
« Reply #1 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.

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Per-project C Preprocessing for tag files?
« Reply #2 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
« Last Edit: June 23, 2007, 01:09:28 pm by hs2 »

cappy2112

  • Community Member
  • Posts: 91
  • Hero Points: 0
Re: Per-project C Preprocessing for tag files?
« Reply #3 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


hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Per-project C Preprocessing for tag files?
« Reply #4 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

cappy2112

  • Community Member
  • Posts: 91
  • Hero Points: 0
Re: Per-project C Preprocessing for tag files?
« Reply #5 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!

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Per-project C Preprocessing for tag files?
« Reply #6 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=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

Kohei

  • Senior Community Member
  • Posts: 192
  • Hero Points: 25
Re: Per-project C Preprocessing for tag files?
« Reply #7 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.
« Last Edit: June 24, 2007, 05:53:15 pm by Kohei »

timur

  • Senior Community Member
  • Posts: 180
  • Hero Points: 3
Re: Per-project C Preprocessing for tag files?
« Reply #8 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.

Kohei

  • Senior Community Member
  • Posts: 192
  • Hero Points: 25
Re: Per-project C Preprocessing for tag files?
« Reply #9 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.

jimlangrunner

  • Senior Community Member
  • Posts: 360
  • Hero Points: 31
  • Jim Lang - always a student.
Re: Per-project C Preprocessing for tag files?
« Reply #10 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)

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Per-project C Preprocessing for tag files?
« Reply #11 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

Graeme

  • Senior Community Member
  • Posts: 2548
  • Hero Points: 329
Re: Per-project C Preprocessing for tag files?
« Reply #12 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

Graeme

  • Senior Community Member
  • Posts: 2548
  • Hero Points: 329
Re: Per-project C Preprocessing for tag files?
« Reply #13 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


hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Per-project C Preprocessing for tag files?
« Reply #14 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