Re: Strange intel fortran compiler issue.

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
--0-965520287-1731101868=:31860
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

Hi all,

Sorry about the lengthy e-mail. Feel free to ignore if you're not 
interested in scons and Fortran. After Mats reply (thank you Mats) to my 
last e-mail, I did a bit more digging.

On Wed, 30 Oct 2024, Mats Wichmann wrote:

> On 10/30/24 09:49, Peter Diener via Scons-users wrote:
>>  Hi all,
>>
>>  I have just encountered a very perplexing issue with SCons when compiling
>>  a Fortran code (with a few C++ files) on a Linux cluster I have gotten
>>  access to.
>
>>  while I run scons -Q --tree=prune -n -f SConstruct.intel
>>
>>  I get:
>>
>>  Evaluating SConstruct.intel
>>  Evaluating module_sudoku.f90
>>  Evaluating reveal.f90
>>  Evaluating /sw/compiler/rrz-wrapper/oneapi-2024.2.1/ifx
>>  Evaluating reveal.x
>>  ifx -o reveal.x -g reveal.f90 module_sudoku.f90
>>  Evaluating .
>>  +-.
>>     +-SConstruct.intel
>>     +-module_sudoku.f90
>>     +-reveal.f90
>>     +-reveal.x
>>       +-reveal.f90
>>       +-module_sudoku.f90
>>       +-/sw/compiler/rrz-wrapper/oneapi-2024.2.1/ifx
>>
>>  showing that scons does not find the dependency on the module.
>
> not just the module, the object files are missing, too.
>
> yes, this is odd looking.  don't actually expect the OneAPI compilers to work 
> at all, there's a tracking issue on that - the whole OneAPI setup depends 
> heavily on environment variables having been set, and you've only fixed for 
> PATH - in kind of a brute-force way, by importing all of it.
>
> There are some known issues with Fortran modules where the dependency is not 
> built correctly, mainly if you're using a variantdir (which you're not). 
> Since the same setup works on a different build host, that seems unlikely to 
> be what you're running into.
>
> Maybe 2024 got even stricter about needing certain env vars than 2022, but 
> that shouldn't cause SCons to fail to build the tree, since that process 
> doesn't involve invoking the compiler.

First of all, I tested whether it was an environment issue by exporting 
the whole environment instead of just the PATH. That had no effect.

Secondly I added a couple of print statement in Executor.scan_sources. The 
first to just make sure that it was called and the second to print out 
which scanner it was called with. I also added a print statment on entry 
to Executor.scan as well as print statments for the nodes in the nodelist. 
Finally I added a print statement on entry to the Fortran scanner. Running 
this on the machine that works I get:

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
executor.scan_sources called
executor.scan: scanner =  None
executor.scan called
executor.scan: node =  .  scanner =  DirEntryScanner
Evaluating SConstruct.intel
Evaluating module_sudoku.f90
executor.scan_sources called
executor.scan: scanner =  SourceFileScanner
executor.scan called
executor.scan: node =  module_sudoku.f90  scanner =  SourceFileScanner
Fortran scanner called
Evaluating /home/packages/compilers/intel/compiler/2022.0.2/linux/bin/ifx
Evaluating module_sudoku.o
Evaluating sudoku.mod
ifx -o module_sudoku.o -c -g -module . module_sudoku.f90
Evaluating reveal.f90
executor.scan_sources called
executor.scan: scanner =  SourceFileScanner
executor.scan called
executor.scan: node =  reveal.f90  scanner =  SourceFileScanner
Fortran scanner called
Fortran scanner called
Evaluating reveal.o
ifx -o reveal.o -c -g -module . reveal.f90
executor.scan_sources called
executor.scan: scanner =  None
executor.scan called
executor.scan: node =  reveal.o  scanner =  None
executor.scan: node =  module_sudoku.o  scanner =  None
executor.scan called
executor.scan: node =  reveal.x  scanner =  ProgramScanner
Evaluating reveal.x
ifx -o reveal.x -g reveal.o module_sudoku.o
executor.scan_sources called
executor.scan: scanner =  None
executor.scan called
executor.scan: node =  .  scanner =  DirEntryScanner
Evaluating .
scons: done building targets.

while on the machine where it doesn't work, I get:

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
executor.scan_sources called
executor.scan_sources: scanner =  None
executor.scan called
executor.scan: node =  .  scanner =  DirEntryScanner
Evaluating SConstruct.intel
Evaluating module_sudoku.f90
Evaluating reveal.f90
executor.scan_sources called
executor.scan_sources: scanner =  None
executor.scan called
executor.scan: node =  reveal.f90  scanner =  None
executor.scan: node =  module_sudoku.f90  scanner =  None
executor.scan called
executor.scan: node =  reveal.x  scanner =  ProgramScanner
Evaluating /sw/compiler/rrz-wrapper/oneapi-2024.2.1/ifx
Evaluating reveal.x
ifx -o reveal.x -g reveal.f90 module_sudoku.f90
scons: building terminated because of errors.

The glaring difference is that Executor.scans_sources are not called on
module_sudoku.f90 at all and when it is called on reveal.f90 the scanner 
argument is set to None.

Any ideas what could cause this?

What determines if Executor.scans_sources is called?

Cheers,

   Peter
--0-965520287-1731101868=:31860
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users

--0-965520287-1731101868=:31860--