2016-02-19 22:48 GMT+01:00 LMH <lmh_users-groups@xxxxxxxxxxx>:
>
>
> Nick Papior wrote:
>> Oh, sorry, I haven't made it clear. I do not want to mix C and fortran.
>> I simply want the preprocessor capabilities in fortran as they work in C.
>> I want to dynamically create a large range of modules/variable-types etc.
>> This is much easier using preprocessors.
>> I know one could do bash/sed/functions/awk/etc combinations to arrive
>> at the same... but... :)
>>
>> 2016-02-19 22:27 GMT+01:00 LMH <lmh_users-groups@xxxxxxxxxxx>:
>>>
>>>
>>> Nick Papior wrote:
>>>> Damnit, I was kind-of hoping this would not break compatibility. :(
>>>>
>>>> Then I guess I am forced to use cpp to create my actual sources.
>>>>
>>>> Thanks for the prompt answer!
>>>>
>>>> PS. Are there options to use the C-processor with gfortran?
>>>> I tried:
>>>> $> gfortran -Xpreprocessor "-x c11-cpp-input" <source>
>>>> f951: Error: command line option ‘-x c11-cpp-input’ is valid for the
>>>> driver but not for Fortran
>>>>
>>>> hrmph...
>>>>
>>>> 2016-02-19 20:30 GMT+01:00 Jonathan Wakely <jwakely.gcc@xxxxxxxxx>:
>>>>> On 19 February 2016 at 19:01, Nick Papior wrote:
>>>>>> Am I missing some point here?
>>>>>> I would have expected gcc/gfortran to use the _same_ preprocessing
>>>>>> utility as that provided in cpp?
>>>>>
>>>>> By default cpp works in C mode, but when invoked by the Fortran
>>>>> front-end it runs in a different mode. If you use cpp -x f97-cpp-input
>>>>> then it works in F95 mode, and you get results consistent with
>>>>> invoking gcc on a .f file, or invoking gfortran.
>>>>>
>>>>> I don't know why cpp treats C and Fortran input differently, but
>>>>> that's why you don't see what you expect.
>>>>
>>>>
>>>>
>>>
>>>> PS. Are there options to use the C-processor with gfortran?
>>>
>>> With g77, if you named your src file with the .FPP extension, the
>>> compiler would run the code through the c pre-processor and then compile
>>> as fortran. This would let you use c style includes and compiler
>>> directives for code compiled as fortran. You cannot use fortran style
>>> includes in the same file (like a common statement), you have to choose
>>> one or the other.
>>>
>>> This is the make rule I used,
>>>
>>> INCLUDES = -I ${SOURCELOC}/src_common_depend
>>> OPTIMIZE = -O2
>>> FCOMP = g77-3
>>> FCFLAGS = $(INCLUDES) $(OPTIMIZE) -mno-cygwin
>>>
>>> $(BDIR)/%.o: $(SOURCELOC)/%.FPP
>>> $(FCOMP) $(FCFLAGS) -c -o $@ $<
>>>
>>> the no-cygwin flag is depreciated and as I said, this example was for
>>> gcc3/g77. I have done some of this with gfortran, but only for linux.
>>>
>>> In some ways, it can be easier to separate your cpp and fortran code and
>>> just have your fortran be a function called from cpp. Let the fortran
>>> have it's own variable namespace and use the fortran pre-processor. As
>>> long as you can send and return what you need to and from the fotrran
>>> function, everything should work fine. It's not supper efficient since
>>> the fortran and c code often have their own copies of each variable, but
>>> that is often not a major issue anymore.
>>>
>>> LMH
>>>
>
> I guess it is not entirely clear to me what you need to do, but you can
> run fortran code through the c preprocessor buy using the .FPP extension
> on your src files and using gfortran as your compiler. I believe that
> was one of the questions asked earlier in the thread.
Yes, the problem is not related to performing the pre-processing.
gfortran pre-process these files:
.fpp, .FPP, .F, .FOR, .FTN, .F90, .F95, .F03 or .F08
The problem is _how_ gfortran preprocesses the files which is not
fully equivalent to the standard cpp pre-processor (Jonathan+ have
stated that is normal behaviour).
>
> Something like,
>
> FCOMP = gfortran
> $(BDIR)/%.o: $(SOURCELOC)/%.FPP
> $(FCOMP) -c -o $@ $<
>
> This would give you fotran objects that were run through the c
> preprocessor to let you use c includes, c comments, macros and compiler
> directives, but prohibit fortran comments and includes, parameter
> statements, common statements, etc.
>
> I have no idea if that helps or not, but it does work.
Thanks for your ideas. But they have already been tried :)
>
> LMH
>
>
>
>
--
Kind regards Nick
