Windows CI silent failure to compile.

[1uc]

Windows CI contains code to guess which headers should be installed. It works by having a list of headers to include in temp.cxx then GCC is used to determine the effective set of headers needed (g++ -E -Iinclude tmp.cxx > temp1). One of the included files is section.h. However, this files hasn't been copied to include in recent version of NEURON.

This failure doesn't cause CI to go red, see:
https://github.com/neuronsimulator/nrn/actions/runs/6249140966/job/16965158784#step:7:3209
for a recent example that had this issue, but overall CI was green. Therefore, this isn't obviously related to #2518.

The full list of files in include is:

+ ls include
backtrace_utils.h
bbsavestate.h
cabvars.h
crout.hpp
crout_thread.hpp
cspmatrix.h
cspredef.h
deflate.hpp
dimplic.hpp
errcodes.hpp
euler.hpp
euler_thread.hpp
hoc.h
hoc_membf.h
hocassrt.h
hocdec.h
hocgetsym.h
hoclist.h
hocparse.h
mcran4.h
md1redef.h
md2redef.h
mech_api.h
membdef.h
membfunc.h
multicore.h
multisplit.h
neuron
neuron.h
newton.hpp
newton_struct.h
newton_thread.hpp
nmodlmutex.h
nrn_ansi.h
nrnapi.h
nrnassrt.h
nrnconf.h
nrncvode
nrncvode.h
nrnisaac.h
nrniv_mf.h
nrnmpi.h
nrnmpidec.h
nrnmpiuse.h
nrnoc_ml.h
nrnran123.h
nrnrandom.h
nrnredef.h
nrnsemanticversion.h
nrnversionmacros.h
oc_ansi.h
ocfunc.h
ocmisc.h
options.h
parse_with_deps.hpp
row_view.hpp
runge.hpp
scoplib.h
section_fwd.hpp
simeq.hpp
sparse.hpp
sparse_thread.hpp
spconfig.h
spmatrix.h
ssimplic.hpp
ssimplic_thread.hpp
treeset.h
wrap_sprintf.h

[nrnhines]

I think you are correct. It wasn't long ago that section.h was an installed include file. Now a truncated version is installed called
section_fwd.hpp
But we clearly haven't updated the nrn/mingw_files/nrnmingwenv.sh fragment

# we rely on a couple of include groups, one from nocmodl and the other one hoi$
copyinc '
"mech_api.h"
"section.h"
<math.h>
...

and, I suppose the equivalent fragment in the windows ci. I believe the fix would simply be to replace section .h with section_fwd.hpp. The goal is to determine all the system include files that are indirectly needed by mod files. I suppose one could consider the first two NEURON include files in the list below to be the primary seeds but I wonder if it might be better to use ALL the files in the NEURON include folder. The remainder of the list below are the literal #include I discovered in modeldb mod files.

I extracted and modified the following from nrnmingwenv.sh into a (linux) build folder and after a successful cmake...; ninja

cat foo.sh
hines@hines-t7500:~/neuron/temp/build$ cat foo.sh
#!/usr/bin/env bash

set -ex

NM=`pwd`/bar
# copy all needed include files by processing output of g++ -E
copyinc() {
  echo "" > temp.cxx
  for i in $* ; do
    echo "#include $i"
  done >> temp.cxx
  echo "int main(int argc, char** argv){return 0;}" >> temp.cxx
  g++ -E -Iinclude temp.cxx  | grep '^#.*include' > temp1
  sed -n 's,^.*/usr/include/,/usr/include/,p' temp1 | sed -n 's,".*,,p' > temp2
  sort temp2 | uniq > temp3
  sed -n 's,/[^/]*$,,p' temp3 | sort  | uniq > temp4
  for i in $(cat temp4) ; do
    mkdir -p "$NM/$i"
  done
  for i in $(cat temp3) ; do
    cp /$i "$NM/$i"
  done
}

# we rely on a couple of include groups, one from nocmodl and the other
copyinc '
"mech_api.h"
"section_fwd.hpp"
<math.h>
<stdio.h>  
<stdlib.h>

<ctype.h>   
<float.h>
<getopt.h> 
<io.h>
<sys/time.h>
<time.h>
<unistd.h> 
<pthread.h>
<pthread_compat.h>
<pthread_signal.h>
<pthread_unistd.h>
'

Then
bash foo.sh generates

-rw-rw-r--  1 hines hines     389 Sep 29 14:26 temp.cxx
-rw-rw-r--  1 hines hines  133048 Sep 29 14:26 temp1
-rw-rw-r--  1 hines hines   90165 Sep 29 14:26 temp2
-rw-rw-r--  1 hines hines   10496 Sep 29 14:26 temp3
-rw-rw-r--  1 hines hines     450 Sep 29 14:26 temp4
drwxrwxr-x  3 hines hines    4096 Sep 29 14:26 bar

where bar contains a hierarchy of all the toolchain include files to be distributed in the installer and the temp files are intermediate steps in the processing of the list in foo.sh. In particular, temp3 is a list of the include file paths and temp4 is a list of the folder names.