RE: [vhdl-200x] conditional compilation proposal

Actually, I think the VHDL community does care about having a language that
encourages reliable and maintainable code. Verilog has the other end of the
spectrum covered :)

The language requirement is for conditional compilation, not for a
preprocessor. A preprocessor is an implementation, not a feature.

Preprocessors are already available and some people use them today. By
addressing conditional compilation within the language, we reduce reliance
on external tools and vendor specific comment directives.

There are definitely ways in which the generate statement could be modified
to meet the requirements of conditional compilation. I think the main
things that are lacking include: a command-line mechanism of control, and
control over declarations. However, it would be necessary to have concrete
use cases to evaluate alternative approaches.

I'm not sure why file inclusion was included in the requirement. It doesn't
seem related.

--Scott Thibault

> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On
> Behalf Of Evan Lavelle
> Sent: Tuesday, August 16, 2011 10:08 AM
> To: vhdl-200x@eda.org
> Subject: Re: [vhdl-200x] conditional compilation proposal
>
> I don't personally agree with this. It's not our problem if users write
ugly
> code. They've got a 30-year-old language, and they already do this, all
the
> time, without our help. And they've spent the best part of 30 years asking
for
> a pre-processor. A pre-processor doesn't break the language grammar, if
it's
> defined as just that - a pre-processor with a separate grammar. It should
> have no impact at all on the main language except for the requirement to
> handle line directives.
>
> A couple of people have suggested an in-language way to handle conditional
> compilation. My own view is that this is not practical in many cases, and
> conditional inclusion pretty much has to be handled in a separate pre-
> processing text translation phase. I'd really like to hear from someone
else
> who has actually written compilers what they think about this. The basic
idea
> is simple. If the user's code is broken in between two preprocessor
> directives, then you simply can't carry out any meaningful analysis on the
text
> stream between those two points; the compiler will just error out. This is
> exactly the problem that generate has, and the reason that the LRM doesn't
> allow bad code in a generate.
> That's why this is done as a separate phase - the pre-processor is much
> simpler, it only has to search for known directives, and it can simply
ignore
> the code in between. In practice, there are some sorts of code that will
catch
> out a preprocessor, but they're not significant.
>
> -Evan
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.