<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>For the compiling gurus:</p>
    <p>I've been working towards finalizing the FUKA importer build
      system for inclusion into the ETK and I've recently added
      additional thorns to the build list to run the test par. For
      completeness, I'm compiling in the following way:</p>
    <blockquote>
      <p>yes | make test-config THORNLIST=thornlist/test.th
        options=test.cfg;<br>
        make test:<br>
      </p>
    </blockquote>
    <p>Currently, all thorns compile successfully except for
      SummationByParts which gives the following error:</p>
    <blockquote>
      <p>/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c:49:17:
        error: redefinition of ‘get_shiftout’<br>
           49 | void CCTK_FCALL CCTK_FNAME(get_shiftout)( const
        CCTK_POINTER_TO_CONST cctkGH_,<br>
              |                 ^~~~~~~~~~~~<br>
/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c:11:6:
        note: previous definition of ‘get_shiftout’ with type
        ‘void(const void * const,  CCTK_INT4 *)’ {aka ‘void(const void *
        const,  int *)’}<br>
           11 | void get_shiftout ( const CCTK_POINTER_TO_CONST cctkGH_,<br>
      </p>
    </blockquote>
    <p>What appears to be happening is that the c_file_processor.pl is
      not handling the generation of creating a fortran function in
      place of CCTK_FNAME so far as I understand it.  For instance, if I
      check the
      `Cactus/configs/test/build/SummationByParts/get_offset.c` file,
      the CCTK_FNAME statement is still there.  Conversely, if I check
      `Cactus/configs/test/build/Boundary/FlatBoundary.c` which also
      uses CCTK_FNAME, these statements have been correctly removed by
      the pre-processor.<br>
    </p>
    <p>Oddly enough, if I run `make test --just-print` I obtain the
      following which suggests that it is at least executing the
      processor correctly.<br>
    </p>
    <blockquote>
      <p>Checking status of thorn
SummationByParts                                                                                                                                                                          
         <br>
        if [ ! -d ./ ] ; then mkdir -p ./ ;
fi                                                                                                                                                                             
         <br>
        cd ./ ; <br>
        make CCTK_TARGET=make.checked
        TOP=/home/user/lib/ETKREL/Cactus/configs/test
        CONFIG=/home/user/lib/ETKREL/Cactus/configs/test/config-data
SRCDIR=/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src
        THORN=SummationByParts USESTHORNS="" -f
        /home/user/lib/ETKREL/Cactus/lib/make/make.subdir{if test yes =
        'yes'; then echo '#line 1
"'/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c'"';
        fi; <br>
            cat
/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c;<br>
        } | perl -s
        /home/user/lib/ETKREL/Cactus/lib/sbin/c_file_processor.pl
        -line_directives=yes
-source_file_name=/home/user/lib/ETKREL/Cactus/arrangements/CactusNumerical/SummationByParts/src/get_offset.c
        /home/user/lib/ETKREL/Cactus/configs/test/config-data &gt;
get_offset.c                                                                                                                               
         <br>
        echo COMPILING
        CactusNumerical/SummationByParts/src/get_offset.c </p>
    </blockquote>
    <p>I have compared the above to the compilation of
      Boundary/src/FlatBoundary.c which compiles successfully and also
      includes the generation of a number of Fortran functions using
      CCTK_FNAME.  So far, no discrepancies have been found that would
      highlight why summationbyparts is failing.<br>
    </p>
    <p>I will continue to try and resolve this, but I hope someone with
      more experience with the pre-processors will be able to shed some
      light on the issue.</p>
    <p>Cheers,</p>
    <p>Samuel<br>
    </p>
  </body>
</html>