[Scons-users] Does SCons work correctly for fortran submodules?
Bill Deegan
bill at baddogconsulting.com
Thu May 31 13:31:35 EDT 2018
Can you file a bug with your sample files on github?
On Thu, May 31, 2018 at 9:42 AM, Peter Diener <diener at cct.lsu.edu> wrote:
> Bill,
>
> I would think that is a correct assumption. Inside the interface block
> the keyword module does not actually define a module but rather tells the
> compiler that the source code for the function or subroutine will be
> provided later in the submodule. I guess you have to take the fact that the
> meaning of module is context dependent up with the designers of the fortran
> standard:-)
>
> Submodules is only required to be present in a Fortran 2008 standard
> compliant compiler but may be provided by Fortran 20003 standard compliant
> compilers.
>
> I don't know whether all compilers handle this in the same way, but I just
> tried ifort and in that case the generate files were:
>
> test_1.mod
> test_1.o
> test_1 at test_1_impl.smod
>
> so except for ifort not generating test_1.smod, the behaviour seems
> similar.
>
> Cheers,
>
> Peter
>
> On Thursday 2018-05-31 11:19, Bill Deegan wrote:
>
> Date: Thu, 31 May 2018 11:19:30
>>
>> From: Bill Deegan <bill at baddogconsulting.com>
>> Reply-To: SCons users mailing list <scons-users at scons.org>
>> To: SCons users mailing list <scons-users at scons.org>
>> Subject: Re: [Scons-users] Does SCons work correctly for fortran
>> submodules?
>>
>> Peter,
>>
>> Yes that what I was looking for.
>> So is it correct to assume the the contents of
>> interface
>> ...
>> end interface
>>
>> Can be ignored as they don't affect the files output by the fortran
>> compiler?
>> (Is this a f90 only feature? or only specify f90 compilers?)
>>
>> -Bill
>>
>> On Thu, May 31, 2018 at 8:52 AM, Peter Diener <diener at cct.lsu.edu> wrote:
>> Hi Bill,
>>
>> What do you mean by actual generated files? Do you mean what
>> files are being generated by the compiler?
>>
>> When compiling with the gfortran -c, test_1.f90 generates:
>>
>> test_1.mod
>> test_1.o
>> test_1.smod
>> test_1 at test_1_impl.smod
>>
>> and similarly for test_2.f90 (with 1 replaced by 2).
>>
>> Cheers,
>>
>> Peter
>>
>> On Thursday 2018-05-31 10:33, Bill Deegan wrote:
>>
>> Date: Thu, 31 May 2018 10:33:23
>> From: Bill Deegan <bill at baddogconsulting.com>
>> Reply-To: SCons users mailing list
>> <scons-users at scons.org>
>> To: SCons users mailing list <scons-users at scons.org>
>> Subject: Re: [Scons-users] Does SCons work correctly
>> for fortran submodules?
>>
>> Took a quick look.
>> It's been a while since I've looked at any fortran
>> and then it was probably
>> fortran 77.
>>
>> Just guessing that scons's scanner/emitter sees
>> this:
>> module function get_n ( this )
>> class(test_type_1), intent(in) :: this
>> integer :: get_n
>> end function get_n
>>
>> And thinks you'll be outputting a module named
>> function from both source
>> files.
>>
>> Can you tell me what the actual generated files are
>> for each of those two
>> source files?
>> My guess is this interface/module/endmodule/end
>> interface syntax isn't being
>> properly handled by SCons
>>
>> -Bill
>>
>> On Thu, May 31, 2018 at 8:14 AM, Peter Diener
>> <diener at cct.lsu.edu> wrote:
>> Hi all,
>>
>> Any thoughts on whether my expectations to
>> SCons are incorrect
>> or whether there is a bug when it comes to
>> compiling fortran
>> source code using type bound procedures in
>> submodules?
>>
>> I can repost my example code that demonstrates
>> the issue if
>> necessary.
>>
>> Cheers,
>>
>> Peter
>>
>> On Thursday 2018-05-03 11:13, Bill Deegan
>> wrote:
>>
>> Date: Thu, 3 May 2018 11:13:01
>> From: Bill Deegan
>> <bill at baddogconsulting.com>
>> Reply-To: SCons users mailing list
>> <scons-users at scons.org>
>> To: SCons users mailing list
>> <scons-users at scons.org>
>> Subject: Re: [Scons-users] Does SCons
>> work correctly
>> for fortran submodules?
>>
>> User's mailing list is the correct place
>> for this
>> query.
>> The developer's mailing list is generally
>> for
>> discussing development of
>> SCons and not really the use thereof.
>>
>> I'll try and look at this later today.
>>
>>
>> On Thu, May 3, 2018 at 11:26 AM, Peter
>> Diener
>> <diener at cct.lsu.edu> wrote:
>> Hi,
>>
>> Any further advice on this issue?
>>
>> Should this go to the developers
>> list?
>>
>> Cheers,
>>
>> Peter
>>
>> On Friday 2018-04-27 16:48, Peter
>> Diener wrote:
>>
>> Date: Fri, 27 Apr 2018
>> 16:48:58
>> From: Peter Diener
>> <diener at cct.lsu.edu>
>> To: SCons users mailing list
>> <scons-users at scons.org>
>> Subject: Re: [Scons-users]
>> Does SCons
>> work correctly
>> for fortran submodules?
>>
>> Hi,
>>
>> A quick update. The release
>> version
>> scons-3.0.1
>> shows exactly the same
>> behavior.
>>
>> Cheers,
>>
>> Peter
>>
>> On Friday 2018-04-27 16:38,
>> Peter Diener
>> wrote:
>>
>> Date: Fri, 27 Apr 2018
>> 16:38:14
>> From: Peter Diener
>> <diener at cct.lsu.edu>
>> Reply-To: SCons users
>> mailing list
>> <scons-users at scons.org>
>> To: SCons users mailing
>> list
>> <scons-users at scons.org>
>> Subject: Re:
>> [Scons-users] Does
>> SCons
>> work correctly for
>> fortran
>> submodules?
>>
>> Hi Bill,
>>
>> I first saw it with an
>> earlier
>> version
>> of SCons. I don't
>> remember which
>> one.
>> Before reporting I
>> wanted to check
>> if it
>> was a bug that was
>> already fixed,
>> so I
>> got the development
>> version. I can
>> try
>> it with the release
>> version as
>> well.
>>
>> scons --tree=prune
>>
>> does not give me any
>> additional
>> information. It gives
>> exactly the
>> same
>> output as just scons.
>>
>> Cheers,
>>
>> Peter
>>
>> On Friday 2018-04-27
>> 14:46, Bill
>> Deegan
>> wrote:
>>
>> Date: Fri, 27 Apr
>> 2018
>> 14:46:35
>> From: Bill Deegan
>>
>> <bill at baddogconsulting.com>
>> Reply-To: SCons
>> users
>> mailing list
>>
>> <scons-users at scons.org>
>> To: SCons users
>> mailing list
>>
>> <scons-users at scons.org>
>> Subject: Re:
>> [Scons-users]
>> Does SCons work
>> correctly
>> for fortran
>> submodules?
>>
>> Peter,
>>
>> Any reason you're
>> using the
>> development
>> version of SCons
>> instead of the
>> released version
>> 3.0.1?
>>
>> What does scons
>> --tree=prune
>> show you?
>>
>> -Bill
>>
>> On Fri, Apr 27,
>> 2018 at
>> 12:04 PM, Peter
>> Diener
>>
>> <diener at cct.lsu.edu> wrote:
>> Hi,
>>
>> Is SCons
>> supposed to
>> work for fortran
>> codes that
>> use submodules
>> and type
>> bound
>> procedures? I have
>> a code
>> project that
>> relies
>> heavily on
>> those
>> features and I
>> would really like
>> to use
>> SCons for it. I
>> was able
>> to produce a
>> small
>> example code that
>> demonstrates the
>> problem I
>> encounter (it
>> only
>> appears with more
>> than one
>> submodule) that I
>> have
>> attached
>> along with the
>> SConstruct file I
>> use.
>>
>> The code
>> example
>> consists of two
>> modules,
>> each containing a
>> fortran type
>> with 2
>> type bound
>> procedures ( a
>> set and get for an
>> integer
>> value). In the
>> module itself the
>> type and
>> the interface
>> to the
>> procedures are
>> defined while the
>> actual
>> implementation of
>> the
>> procedures are done
>> in the submodules.
>> Normally
>> I would keep
>> the module
>> and
>> corresponding
>> submodule in
>> different files to
>> separate the
>> interface
>> and
>> implementations.
>>
>> When I run
>> scons on
>> this example, I
>> get:
>>
>> scons:
>> Reading
>> SConscript files
>> ...
>>
>> scons: ***
>> Multiple
>> ways to build the
>> same
>> target were
>> specified
>> for:
>> function.mod
>> (from
>> ['test_1.f90'] and
>> from
>> ['test_2.f90'])
>>
>> Is my
>> SConstruct file
>> incorrect, should
>> I not
>> expect SCons to be
>> able to
>> handle such a
>> case or is this a
>> bug?
>>
>> My SCons is
>> an up to
>> date checkout of
>> the GitHub
>> repository,
>> i.e.
>>
>> scons
>> --version
>>
>> gives:
>>
>> SCons by
>> Steven Knight
>> et al.:
>>
>> script:
>>
>>
>>
>> v3.1.0.alpha.yyyymmdd.867f762f6c1e23524cd1b0262b8e93e822
>> b23d0c
>>
>> Note, the
>> example code
>> compiles correctly
>> with a
>> sufficiently
>> new version
>> of gfortran
>> and the command
>> line:
>>
>> gfortran
>> test_1.f90
>> test_2.f90
>>
>> test_submodules.f90 -o
>>
>> test_submodules.x
>>
>> Thank you in
>> advance
>> for any advice.
>>
>> Cheers,
>>
>> Peter
>> Diener
>>
>>
>>
>>
>> _______________________________________________
>> Scons-users
>> mailing
>> list
>>
>> Scons-users at scons.org
>>
>>
>>
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>>
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>>
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>>
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>>
>>
>>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180531/a0426d2c/attachment-0001.html>
More information about the Scons-users
mailing list