search

zerothi / fdict

Fortran type-free variable and type-free dictionary
http://zerothi.github.io/fdict
Mozilla Public License 2.0
75 stars 17 forks source link

Compilation on Mac OS X #2

Closed jacopo-chevallard closed 8 years ago

jacopo-chevallard commented 8 years ago

Nice project !!

In order to compile on my Mac OS X 10.9.5 (gfortran 5.2) I add to replace cpp ---> fpp on line 17 of the Makefile.

Also, the free system command seems not to be present (on bash or zsh) on Mac OS, hence the memory tests will give the output

 Running with deallocation
sh: free: command not found

Finally, there was a small bug in dictionary_pp.F90: the lines 306 and 307 must be inverted, i.e.

    chash = ld%hash
    ld => this%first

becomes

    ld => this%first
    chash = ld%hash
zerothi commented 8 years ago

Thanks!

Fixed in e0f0023.

zerothi commented 8 years ago

I will not correct the free "bug" as it merely is a test with additional information. It will not error out as it is called without status checks.

jacopo-chevallard commented 8 years ago

You're welcome! And yes, I agree that the lack of the free is not a big issue, maybe worth keeping this in mind and adding it somewhere in the Known Issues for Mac OS X section of a README

zbeekman commented 8 years ago

@jacopo-chevallard: I'm curious what the error you're seeing is. There may be a more suitable work around to pass different flags to cpp, rather than using the (non-free) Intel preprocessor with GFortran...

Also, is it necessary to explicitly pre-process the source files in the makefile? If they end in capital .F90 the compiler should invoke the correct tool, no?

jacopo-chevallard commented 8 years ago

If I copy the arch-makes/gfortran.make to the top-level directory, and run make, I get the errors below, i.e. it seems that part of variable_pp.F90 is not correctly pre-processed

/Users/jchevall/Coding/External/fdict/var.sh
cpp -E -P -C -nostdinc   -I. -I/Users/jchevall/Coding/External/fdict /Users/jchevall/Coding/External/fdict/variable_pp.F90 \
        | sed -f /Users/jchevall/Coding/External/fdict/filter.sed > tmp.F90 2> /dev/null
cpp -E -P -C -nostdinc   -I. -I/Users/jchevall/Coding/External/fdict tmp.F90 \
        | sed -f /Users/jchevall/Coding/External/fdict/filter.sed > variable.f90 2> /dev/null
gfortran -c  -O3 -m64 -fPIC -fno-second-underscore -ftree-vectorize -fexpensive-optimizations -finline-functions-called-once -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-optimize -frename-registers -fprefetch-loop-arrays -finline-small-functions -fipa-pure-const -foptimize-sibling-calls -fipa-cp iso_var_str.f90
gfortran -c  -O3 -m64 -fPIC -fno-second-underscore -ftree-vectorize -fexpensive-optimizations -finline-functions-called-once -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-optimize -frename-registers -fprefetch-loop-arrays -finline-small-functions -fipa-pure-const -foptimize-sibling-calls -fipa-cp variable.f90
variable.f90:6429:12:

   this%t = #i0
            1
Error: Invalid character in name at (1)
variable.f90:6447:23:

   lsuccess = this%t == #i0
                       1
Error: Syntax error in expression at (1)
variable.f90:6467:23:

   lsuccess = this%t == #i0
                       1
Error: Syntax error in expression at (1)
variable.f90:6507:12:

   this%t = #i0
            1
Error: Invalid character in name at (1)
variable.f90:6521:18:

   ret = this%t == #i0
                  1
Error: Syntax error in expression at (1)
variable.f90:6536:18:

   ret = this%t == #i0
                  1
Error: Syntax error in expression at (1)
variable.f90:6593:12:

   this%t = #i1
            1
Error: Invalid character in name at (1)
variable.f90:6611:23:

   lsuccess = this%t == #i1
                       1
Error: Syntax error in expression at (1)
variable.f90:6639:23:

   lsuccess = this%t == #i1
                       1
Error: Syntax error in expression at (1)
variable.f90:6679:12:

   this%t = #i1
            1
Error: Invalid character in name at (1)
variable.f90:6693:18:

   ret = this%t == #i1
                  1
Error: Syntax error in expression at (1)
variable.f90:6708:18:

   ret = this%t == #i1
                  1
Error: Syntax error in expression at (1)
variable.f90:6765:12:

   this%t = #i2
            1
Error: Invalid character in name at (1)
variable.f90:6783:23:

   lsuccess = this%t == #i2
                       1
Error: Syntax error in expression at (1)
variable.f90:6811:23:

   lsuccess = this%t == #i2
                       1
Error: Syntax error in expression at (1)
variable.f90:6851:12:

   this%t = #i2
            1
Error: Invalid character in name at (1)
variable.f90:6865:18:

   ret = this%t == #i2
                  1
Error: Syntax error in expression at (1)
variable.f90:6880:18:

   ret = this%t == #i2
                  1
Error: Syntax error in expression at (1)
variable.f90:6937:12:

   this%t = #i3
            1
Error: Invalid character in name at (1)
variable.f90:6955:23:

   lsuccess = this%t == #i3
                       1
Error: Syntax error in expression at (1)
variable.f90:6983:23:

   lsuccess = this%t == #i3
                       1
Error: Syntax error in expression at (1)
variable.f90:7023:12:

   this%t = #i3
            1
Error: Invalid character in name at (1)
variable.f90:7037:18:

   ret = this%t == #i3
                  1
Error: Syntax error in expression at (1)
variable.f90:7052:18:

   ret = this%t == #i3
                  1
Error: Syntax error in expression at (1)
make: *** [variable.o] Error 1
zerothi commented 8 years ago

Yes, but sadly a lot of functionality from the fortran pre-processors are not compatible with regular C-preprocessor statements.

As can be seen from the previous comment this quickly arises when you do "stringification" and/or concatenation of multi-level preprocessor flags, and also with multi-level includes (if I remember correctly).

Essentially the automatic fortran preprocessor is a very crude subset of the C preprocessor. Just try creating some simple functions and you will see :)

Hence, it is forced to be preprocessed "off-compiler". :(

zerothi commented 8 years ago

To comment on @jacopo-chevallard, supporting different preprocessors is a night-mare.

Once I have fixed #1 the code will be shipped in the release tarball such that pre-processing is not necessary (for the basic usage). If one needs to re-create the sources they will have to get their PP command to work. :)

jacopo-chevallard commented 8 years ago

Btw, you should take a look at this new Python-based Fortran pre-processor (fypp), it is very simple and powerful, and free!

jacopo-chevallard commented 8 years ago

Another suggestions for #1, I find CMake much simpler to use than building different Makefiles for different OS, compilers, etc...

zerothi commented 8 years ago

Yes, I have seen that before. But I would rather not have to rely on some 3rd party tool.

The gfortran 4.8 (and upwards, haven't tested backwards) are shipped with a nice preprocessor which eats everything :)

Besides, fypp has a 3rd language which I am not keen on implementing.
Most people will have a slight idea of CPP and hence relying on this is fine.

I have considered many other options such as old-school m4 or other tools.

zerothi commented 8 years ago

Hmm, I really do not like CMake! I will not implement support for it (somebody else has to do the work :) ).

CMake's deficiency becomes apparent when you start compiling different tools with customizable options. Have you tried compiling Clang with custom paths for the dependencies? It is a nightmare.

One problem is that CMake does not enforce a strict naming scheme for dependency options such as paths, libraries, includes etc. Nearly every project which uses CMake introduces a different naming scheme: LAPACK_PATH vs. PATH_LAPACK vs. LA_PATH etc. And even fewer projects provides the necessary documentation to control them individually.

CMake would be good if everybody added CMake functions to their projects to extract such information, thus relieving dependent projects of re-implementing search functions.

PS. Feel free to make a PR with CMake, it can't hurt as long as it does not interfere ;)

jacopo-chevallard commented 8 years ago

Agree with the above limitations of CMake, but if the goal is to provide a simple, compiler-indepednent way to compile the program, then it makes an excellent too (in my experience). And sure, I can provide a PR for it!

zerothi commented 8 years ago

Great. :)

2016-04-15 16:37 GMT+02:00 Jacopo Chevallard notifications@github.com:

Agree with the above limitations of CMake, but if the goal is to provide a simple, compiler-indepednent way to compile the program, then it makes an excellent too (in my experience). And sure, I can provide a PR for it!

— You are receiving this because you were assigned. Reply to this email directly or view it on GitHub https://github.com/zerothi/fdict/issues/2#issuecomment-210486427

Kind regards Nick