264 reserved header include guard

[guitorri]

Fix all header include guards. The leading underscore is reserved to the C++ implementation. Uppercase is a common convention. This closes issue #264.

[guitorri]

Some headers are quite generic (VARIABLE_H, ANALYSIS_H, APPLICATIONS_H). If we ever become serious about an API, this could be a problem.
Should we prefix all header include guards with something particular to Qucs (QUCS_)?

[in3otd]

makes sense anyway... I saw around that some proposes to use macro names like PROJECT_DIR_HEADERNAME so we will have something like QUCS-CORE_COMPONENTS_MICROSTRIP_MSBEND_H ...this is maybe a bit too much.

[guitorri]

Perhaps just PROJECT_HEADERNAME ?

[in3otd]

yes, just PROJECT_HEADERNAME seems better for Qucs.

(Somewhat unrelated, maybe one day we should also change the qucs-core directory name to qucsator, since we are going to support several simulators)

[guitorri]

Rebased.
I will do to theQUCS_HEADERNAME throughout.
And revert to $(MODULE)_H to VA_$(module)_H` for adms/veriloga files

[felix-salfelder]

hmm, any reason, we should not switch header guards to #pragma once? seems to be widely supported, and less messy.

[guitorri]

Didn't know about it.
Got mixed feeling after reading this:
http://stackoverflow.com/questions/1143936/pragma-once-vs-include-guards

[felix-salfelder]

yes, there may be pitfalls (that were not entirely clear to me).
if conventional guards works, we should maybe stick to it.

iirc, we had once fixed output filenames, to get $(FILE).cpp from $(FILE).va... using that logic, wouldn't VA_$(FILE)_H, or VA_$(FILE)_$(MODULE)_H make (a bit) more sense?

[felix-salfelder]

Most of this is Qucsator (it needs rebase). The other bits seem obsolete, as most plugins don't need header guards.