Author Topic: per-project preprocessing  (Read 1707 times)

warnerrs

  • Senior Community Member
  • Posts: 114
  • Hero Points: 4
per-project preprocessing
« on: November 24, 2016, 08:44:42 pm »
Ideally, I think preprocessing macros should be able to be defined per-project.

But short of that, is anyone managing per-project macro definitions? And what process are you using to avoid deleting the existing set of macros, and loading another set? Only solution I'm seeing right now is to use completely separate options via the -sc option when starting.

Graeme

  • Senior Community Member
  • Posts: 2445
  • Hero Points: 322
Re: per-project preprocessing
« Reply #1 on: November 26, 2016, 05:40:02 am »
Did you know that slick lets you define pre-processing symbols per workspace?  Project -> workspace properties -> c/c++ Preprocessing.  You could have one project per workspace.

warnerrs

  • Senior Community Member
  • Posts: 114
  • Hero Points: 4
Re: per-project preprocessing
« Reply #2 on: November 26, 2016, 06:56:14 pm »
Thanks, hadn't noticed that. Now I also need support workspace specific SystemVerilog preprocessor macros.

jporkkahtc

  • Senior Community Member
  • Posts: 1902
  • Hero Points: 184
  • Text
Re: per-project preprocessing
« Reply #3 on: November 28, 2016, 10:32:37 pm »
Odd that these aren't workspace specific.
The C/C++ preprocessor defines in WORKSPACENAME_cpp.h.

The verilog ones ought to use the same sort of pathname that then C++ preprocessor defines do.

PPEDIT.e does this:
   path := _ConfigPath():+"usersystemverilog.svh";

Where tagform.e does:
   return workspace_basename :+ "_cpp.h";

But the code that uses usersystemverilog.svh doesn't expect there to be more than one, whereas the C/C++ code does.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2934
  • Hero Points: 438
Re: per-project preprocessing
« Reply #4 on: November 29, 2016, 04:21:13 pm »
I took a keep-it-simple approach to System Verilog preprocessing.  The expectation was that it would be used more for library code than user code, so it would not need to be configurable at the workspace level like it is in C++.  I will file a feature request to implement per-workspace preprocessing configuration for System Verilog in a future release.

@warnerrs:  Are you using the same defines in different ways (with significantly different definitions) for different workspaces?  What I am asking is if per-workspace configuration is a necessity for you, or just better organization that mashing everything you need into the global configuration?  Keep in mind, we are talking about preprocessing here, so there isn't a practical reason for anything to be pretty.  Preprocessing is ugly, no matter what language is besmirched by it (IMHO).

warnerrs

  • Senior Community Member
  • Posts: 114
  • Hero Points: 4
Re: per-project preprocessing
« Reply #5 on: November 29, 2016, 10:52:20 pm »
The UVM preprocessor macros are for library code that will be shared between all workspaces, this works fine for that and is the most important feature. These are the big complicated kinds of macros that take parameters and expand into code.

On a project basis ( that's my project, not an SE project ) I define simple constant style macros. That are either used as constant values or control `ifdefs. `ifdef control is the most important here, and this affects RTL more than testbench code. However there are a few that apply to the testbench, which is what I'm most concerned about.
`define/undef FULL_DEBUG
`define/undef ASSERT_ON

Some projects I work on only have a handful of defines like this. Others have a defines file that is pages long controlling what features are enabled in macro controlled, parameterized code.

If I adopt a separate configuration per workspace I can work around this until you add the feature. Have you ever considered layered configurations? You know, look for an SE configuration in path search order where you merge the results? Maybe it's too hard to come up with priority rules that work for all options, but a thought.