Inconsistent project name and CMake options

[pramodk]

@tristan0x has following comment in PR here:

For brevity we (including Michael) prefer NRN instead of NEURON.

It would be ok to rename project name from NEURON to NRN provided that this doesn't affect other places. For example:

• wheel should still be named as NEURON and not NRN

[nrnhines]

I prefer to keep the project name as the more descriptive NEURON and also because that has been
its face to the world for many years. Internal code names are generally the short nrn form. I do believe
there is a kind of consistency in all this except for a few cases. NEURON generally refers to the large ecosystem and is also occasionally referred to as The NEURON Simulation Environment

[pramodk]

I also see the point of having NRN as well as NEURON in different context.

I created this issue because we are using some utilities for code-formatting which automatically creates CMake options by using project name i.e.

If we enable code formatting as:

$ cmake .. -DNEURON_CMAKE_FORMAT=ON -DPYTHON_EXECUTABLE=`which python3`

Then following CMake variables are created:

One way would be to optionally tell coding-convention utility to use NRN instead of project name.

Is that possible @tristan0x ?

cc: @ohm314

[nrnhines]

If the coding convention utility can be made to use NRN then great. Otherwise I think the only choice is to leave some mixed NEURON and NRN or to universally in cmake change all NRN to NEURON. I don't mind except for the trivial extra name lengths and the cursing that results when one types NERUON

[ohm314]

I think we should be able to adjust hpc-coding-conventions to take the desired name. If that is not possible, I also opt for using "NEURON" everywhere (and do some cursing :) )

[nrnhines]

everywhere @ohm314

I'm guessing your context is a bit narrower than that and refers only to the cmake options. The reasons NRN and nrn are so ubiquitous is their convenience. The 'nrniv', 'nrnoc', letter groups as well as strange names like nocmodl had perfectly reasonable origins in the oc, nrnoc, ivoc, nrniv folder structure but don't make as much sense as they used to.

[ohm314]

Yes, I meant in the context of cmake / the build system. in the source code I would think there is no need to rush with radical name changes and rather change names whenever it makes sense and eases maintenance or clarifies code.

[pramodk]

@ohm314 has done necessary change in BlueBrain/hpc-coding-conventions@0673881