Windows wheels

[Helveg]

There wasn't an official issue yet for this feature, so with this: Please provide Windows wheels. I understand that the Windows installer of NEURON does a lot more than what wheels do, but it ought to be tracked somewhere it could gather traction either way. Having NEURON pip installable cross-platform has educational value and makes it a nicer dependency to deal with for package authors.

[JCGoran]

Windows wheels require native Windows builds first, and #2746 and #2589 are a step in that direction.
Unfortunately, due to lack of both manpower and resources (I personally do not run Windows anywhere), it is not a priority at the moment.
However, if you or someone else is willing to work on this (either from scratch or finishing up the above PRs), I'd be more than happy to review it.

[Helveg]

@nrnhines we've been attempting windows builds in Friday afternoon sessions (Europe time), and we got the build "working". Now we're starting to hit esoteric HOC problems (and we have problems with the stability/reproducibility of the debug symbols in the build). Is there any chance you'd be able to hop on for some of these sessions to get us more familiar with debugging HOC?

An example is that the HOC parser throws a syntax error for every possible statement, even a = 1 or 1, which are valid statements when I execute them in a Linux build.

[ramcdougal]

It's not a line break encoding issue is it? Windows uses two characters for those, Linux and Mac use one.

[nrnhines]

@Helveg

able to hop on for some of these sessions

Yes! I'm delighted this is being worked on and will definitely participate. I'm starting close to 0 though. I'm not having good experience with virtualbox in terms of performance (windows 11 guest, ubuntu 24.04 host, virtualbox 7.0.15). Where is latest info about preparing the development environment. Some months ago I tried following https://nrn.readthedocs.io/en/latest/install/windows.html

[Helveg]

@ramcdougal we tried a variety of inputs (\n, \r\n and \r) and I tried to replace \n with \r somewhere in the YACC parser but those only accepted a single character and didn't know how to maybe try \r\n there.

[nrnhines]

What pull request or branch is being used currently? I see that #2589 has many conflicts with the current master.
The last comment, Jun 18, for that PR mentions

I'm wondering if the line-ending treatment is not the root cause of the error?

Is the present idea to fix that before resolving the conflicts?

Nevermind, I see #3525

[nrnhines]

I've started a pr #3565 to experiment with and at the moment I'm nervous about the setting up with windows development environment with respect to following https://nrn.readthedocs.io/en/latest/install/windows.html
I've intalled the Pre-requisites: git, chocolatey, visual studio community 2022, and pwsh
but "Build Environment installation" refers to scripts in master that do not exist in the hines/windows-wheels branch such as ci\win_download_deps.cmd . I'm open to suggestions about how to proceed.

[Helveg]

It seems you've found the branch we were using! It was indeed jelic/windows-merge-attempt-1. What is your situation so far? Does the build succeed for you? We can configure the CMAKE build on Windows using MSVC, and Flex/Bison/YACC/... installed via Chocolatey, and the build succeeds, but then during some sort of hoc obj install/init the HOC parser throws a syntax error.

Is your situation the same?

[nrnhines]

I'm having trouble with cmake.

PS C:\Users\micha\neuron\nrn> & "C:\Program Files\CMake\bin\cmake" -B build -S . -DCMAKE_BUILD_TYPE=Debug -DPYTHON_EXECUTABLE=C:\Python312\python.exe -DBISON_EXECUTABLE=C:\ProgramData\chocolatey\bin\win_bison -DFLEX_EXECUTABLE=C:\ProgramData\chocolatey\bin\win_flex -DNRN_ENABLE_MPI=OFF -DNRN_ENABLE_RX3D=OFF
...
-- Found BISON: C:/ProgramData/chocolatey/bin/win_bison (found version "3.7.4")
CMake Error at C:/Program Files/CMake/share/cmake-4.1/Modules/FindPackageHandleStandardArgs.cmake:227 (message):
  Could NOT find FLEX: Found unsuitable version "win_flex.exe 2.6.4", but
  required is at least "2.6" (found C:/ProgramData/chocolatey/bin/win_flex)
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-4.1/Modules/FindPackageHandleStandardArgs.cmake:589 (_FPHSA_FAILURE_MESSAGE)
  C:/Program Files/CMake/share/cmake-4.1/Modules/FindFLEX.cmake:466 (find_package_handle_standard_args)
  CMakeLists.txt:358 (find_package)

I'm using choco install in a powershell with admin privileges to install. And a normal powershell to build. At the moment

PowerShell 7.5.2
PS C:\Windows\System32> choco list
Chocolatey v2.3.0
chocolatey 2.3.0
cmake 4.1.0
cmake.install 4.1.0
sed 4.9.0
winflexbison3 2.5.24.20210105
5 packages installed.

[nrnhines]

I temporarily worked around the flex issue with

-find_package(FLEX 2.6 REQUIRED)
+find_package(FLEX 2.6)

But now I'm experiencing a dozen or so

C:\Python312\Include\pyconfig.h(225,13): error C2632: 'int' followed by 'int' is illegal [C:\Users\micha\neuron\nrn\bui
ld\src\nrnpython\nrnpython.vcxproj]
  (compiling source file '../../../src/nrnpython/nrnpython.cpp')

where the offending line in pyconfig.h is

typedef int pid_t;

This is worrisome as no one else seems to be having these difficulties.

[Helveg]

We configure it without Python for the moment being, perhaps that's why. My choco list also has winflexbison, version 2.4.9.20170215, on top of that I also have sed 4.9.0 which I presume is for this build too

[nrnhines]

Ok. At least looks like we are inhabiting the same universe. All my different linkage errors were resolved with the pattern

-extern "C" int ECS_insert(int grid_list_index,
+extern "C" NRN_EXPORT int ECS_insert(int grid_list_index,

and now I'm seeing

LINK : fatal error LNK1104: cannot open file 'python312_d.lib' [C:\Users\micha\neuron\nrn\build\src\nrniv\nrniv_lib.vcx
proj]

So maybe I should defer the default and use -DNRN_ENABLE_PYTHON=OFF

[nrnhines]

I see the symptom more closely but not the bug itself. The problem is the execution of the wrong parser rule. I.e adding the printfs in src/oc/parse.ypp

objvarlst1: obvarname
		{code(hoc_objvardecl); hoc_codesym($1); hoc_codei(0); printf("objvarlst1: obvarname --- %s\n", $1->name);}
	| obvarname numdimen
		{code(hoc_objvardecl); hoc_codesym($1); hoc_codei($2);printf("objvarlst1: obvarname numdimen --- %d\n", $2);}

I see the output

NEURON -- VERSION 9.0a-1542-ge76ca8097 hines/winwheel (e76ca8097+) 2025-08-11
Duke, Yale, and the BlueBrain Project -- Copyright 1984-2022
See http://neuron.yale.edu/neuron/credits

calling hoc_oc
getline |objref hoc_obj_[2]
|
objvarlst1: obvarname --- hoc_obj_
hoc_oc caught exception: hoc_execerror: syntax error

whereas the correct printf line is the one for the obvarname numdimen production.

objvarlst1: obvarname numdimen --- 1

which, e.g. happens for a linux test. My next question is how/if the linux bison generated parse.cpp differs from the windows generated parse.cpp.