[Scons-users] Does SCons work correctly for fortran submodules?
Bill Deegan
bill at baddogconsulting.com
Thu May 31 12:19:30 EDT 2018
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.867f762f6c1e23524cd1b0262b8e93e822b
>> 23d0c
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180531/bad31543/attachment-0001.html>
More information about the Scons-users
mailing list