jacobwilliams / json-fortran

A Modern Fortran JSON API

JSON-Fortran: A Modern Fortran JSON API

Table of Contents

• JSON-Fortran
  • Status
  • Brief description
  • Download
  • Building the library
  • Documentation
  • Contributing
  • License
  • Miscellaneous

Status

Take a look at the CHANGELOG for a list of changes since the latest release.

top

Brief description

JSON-Fortran is a user-friendly, thread-safe, and object-oriented API for reading and writing JSON files, written in modern Fortran.

top

Download

Download the official versioned releases here. Or, get the latest development code from the master branch here.

NEWS: As of June 7, 2015, json-fortran can be downloaded and installed with the homebrew package manager on Mac OS X. Once homebrew is installed, make sure that the formulae are up to date, view the package options and caveats, and install the json-fortran formula:

brew update
brew info json-fortran
brew install --with-unicode-support json-fortran

Please note, if you wish to support usage of JSON-Fortran with multiple Fortran compilers, please follow the CMake installation instructions below, as the homebrew installation is only intended to support a single Fortran compiler. Cheers!

NEWS: As of January 20, 2022, json-fortran can be downloaded and installed via the conda package manager on Mac OS X and Linux. Once a conda-distribution, like miniforge, is installed the json-fortran package can be installed.

conda install json-fortran

Note: Packages on conda-forge are build with GCC 9.4 which is upwards compatible with newer GCC versions, but not with other Fortran compilers.

top

Building the library

The code requires a Fortran compiler that supports various Fortran 2003 and Fortran 2008 features such as: allocatable strings, newunit, generic, class, and abstract interface. It has been successfully compiled with the Intel Fortran compiler 13.1.0 (and greater) and the GNU gfortran compiler [4.9 and greater]. It has also been reported that the library can be built (using the CMake build script) with the NAG Fortran compiler 6.0

Currently, several ways are provided to build the JSON-fortran library (libjsonfortran).

• A build script, build.sh is provided in the project root directory. This script uses FoBiS to build the JSON-Fortran library and the unit tests on Unix-like systems. Edit the script to use either the Intel Fortran Compiler or Gfortran. Note that version 1.2.5 of FoBiS (or later) is required.

• A FoBiS configuration file (json-fortran.fobis) is also provided that can also build the library and examples. Use the mode flag to indicate what to build. For example:

  • To build all the examples using gfortran: FoBiS.py build -f json-fortran.fobis -mode tests-gnu
  • To build all the examples using ifort: FoBiS.py build -f json-fortran.fobis -mode tests-intel
  • To build a static library using gfortran: FoBiS.py build -f json-fortran.fobis -mode static-gnu
  • To build a static library using ifort: FoBiS.py build -f json-fortran.fobis -mode static-intel

  The full set of modes are: static-gnu, static-gnu-debug, static-intel, static-intel-debug, shared-gnu, shared-gnu-debug, shared-intel, shared-intel-debug, tests-gnu, tests-gnu-debug, tests-intel, tests-intel-debug

  To generate the documentation using ford, run: FoBiS.py rule --execute makedoc -f json-fortran.fobis

  To run all the tests, run: FoBiS.py rule --execute tests -f json-fortran.fobis

• A Visual Studio project is included for building the library (and unit tests) on Windows with the Intel Fortran Compiler. The project has been tested with Visual Studio 2010 and 2013.

• A CMake build system is provided. This build system has been tested on Mac and Linux using the Intel Fortran Compiler, gfortran 4.9, and NAG Fortran 6.0. It does also work on Windows (but note that the Visual Studio project it generates is not quite the same as the one mentioned above). This CMake based build provides an install target, and exports from both the install location and the build location so that building and using JSON-Fortran in another CMake based project is trivial. To get started with the CMake based build, set the environment variable FC to point to your Fortran compiler, and create a build directory. Then (cmake-gui|ccmake|cmake) /path/to/json-fortran-root to configure, make to build and make install to optionally install. You can also use make check to build and run the unit tests. As long as the project is built with CMake, other CMake projects can find it and link against it. For example, if you have a second copy of the JSON-Fortran project tree, and want to build the unit tests linking against those compiled/installed by the first copy:

cmake_minimum_required ( VERSION 2.8.8 FATAL_ERROR )
enable_language ( Fortran )
project ( jf_test NONE )

find_package ( jsonfortran-${CMAKE_Fortran_COMPILER_ID} 8.4.0 REQUIRED )

file ( GLOB JF_TEST_SRCS "src/tests/jf_test_*.F90" )
foreach ( UNIT_TEST ${JF_TEST_SRCS} )
  get_filename_component ( TEST ${UNIT_TEST} NAME_WE )
  add_executable ( ${TEST} ${UNIT_TEST} )
  target_link_libraries ( ${TEST} jsonfortran::jsonfortran-static )
  # or for linking against the dynamic/shared library:
  # target_link_libraries ( ${TEST} jsonfortran::jsonfortran ) # instead
endforeach()

• A Fortran Package Manager file is also included, so that JSON-Fortran can be compiled with FPM.

top

Documentation

The API documentation for the latest release version can be found here. The documentation can also be generated by processing the source files with FORD. Note that both the shell script and CMake will also generate these files automatically in the documentation folder, assuming you have FORD installed.

Some examples can also be found on the wiki.

top

Contributing

Want to help? Take a quick look at our contributing guidelines then claim something and Fork. Commit. Pull request.

top

License

The JSON-Fortran source code and related files and documentation are distributed under a permissive free software license (BSD-style). See the LICENSE file for more details.

top

Miscellaneous

• JSON-Fortran is a fork and extensive upgrade of the Fortran 95 FSON code. The reason for the split was to be able to incorporate object-oriented and other nice features of the Fortran 2003 and 2008 standards. Many thanks to the original authors of FSON.
• For more information about JSON, see: http://www.json.org/
• json-fortran on Codecov.IO

top

json-fortran's Issues

Tests directory should be subdirectory of src

While working on #27 and #30 I discovered that ROBODoc is no longer building documentation for the tests/ because it has been moved outside of src/ and ROBODoc only accepts one --src flag. Telling ROBODoc to look in the project root is less than ideal because CMake copies the source files to a build directory which I usually keep as an un-versioned subdirectory of the project root. My proposed solution is to move tests/ into src/ so that ROBODoc will recursively find the test sources too, without finding copies of sources in the build tree.

logic of top level if construct in json_get_double

json_get_double, json_get_integer and the like all start by immediately branching into an if statement:

if (.not. exception_thrown) then
    ! Do the work
else
    value = 0.0_RK
    if (present(found)) found = .false.
end if
end subroutine

I traced this through the git history, using the ‘blame’ functionality on github, and this dates back to the initial commit.

To me, the logic of this is unnecessary, and possibly wrong. Under what circumstances would we anticipate exception_thrown to be true upon entry, and want to set the value to 0.0 and return?

The only suspect I can think of is the array callback stuff, but I can’t seem to figure out why we would want this in this case either…

optional dummy arguments dereferenced outside of if (present(…)) check

This happens in a number of places when calling throw_exception… It’s possible that the code is coded in such a way that can never get here, but to be safe I’ll work up a PR that patches this.

Unicode support

The library does not currently support non-escaped Unicode characters (as required by the JSON standard). Presumably, this could be fixed by defining the character kind as:

integer,parameter :: CK = SELECTED_CHAR_KIND('ISO_10646')

However, this is not currently supported on the Intel compiler. So for now, I will leave this as a known bug. See also the comments at the end of 0066f7d

Intel broke

Commit e636f96 seems to be causing problems when compiled on v2015 Intel compiler. Will look into it.

Validate hex values in strings

Add a feature to validate any hex values that are in strings (either when the file is parsed, or the string is retrieved). Possibly throw an error if try to read a JSON file with an invalid hex string.

Added a routine that I'll use for this task eventually: b7444ac

writing err_message without call to throw_exception in son_parse

I think this might be a bug: son_parse writes an err_message without calling throw_error but I am not 100% sure. What do you think @jacobwilliams?

Intel compiler bug triggered by d2622a86f076f041ad8c971c42c42f7c5310f45b

My version of the Intel compiler doesn’t like having multiple TBPs declared in one procedure :: … statement. The fix is easy: move each TBP (introduced in d2622a8) to its own line. I’m working up a pull request with this and some other stuff, so you can wait until I submit it if you like, rather than fixing it yourself. https://software.intel.com/en-us/forums/topic/538422

Performance penalty of SEQUENCE

Check to see if the SEQUENCE attribute in json_value is causing any noticeable performance penalty. See Issue #34

Arrays

Consider storing 1D arrays (integer, real, and logical) within one json_value node as actual allocatable arrays, rather than constructing a linked list for each element of the array. This would provide more efficient access.

CMake Tests 3 and 8 fail due to new test case, example 6, added in e636f96

The CMake tests are crude, and intentionally introducing an invalid json file and diagnosing the error is causing CTest to hit on the ‘error’ regex and incorrectly say that the test has failed.

My preferred fix would be to break up the json_example.f90 file into individual tests, one per file, then they could be tested one by one. What do you think @jacobwilliams ?

Create a tag/release

I think that the code is pretty usable at this point. A good way to indicate this to potential end users would be to create and push a tag, and possibly a release. If you create a release, you could create a zip of a clean source tree and add that to the release page, so that it can be used without git.

Concerning tags: I think semantic versioning is the way to go, and when you make changes in the future (including when accepting pull requests) please don’t forget to update the tag version and the version in the CMakeLists.txt.

CMake build does not build the example program or run tests

I will submit a pull request with edits enabling tests. I’m not sure what you do to test the code, but I figure you use the json_example program. I was thinking of implementing the following tests with it:

1. sniff test: ensure it compiles and runs
2. validate JSON written to stdout and JSON files written with jsonlint
3. If on Linux use valgrind to check for memory leaks?

CMake fails due to robodoc.rc

Bug introduced in 2a9ce5c
Needs an absolute path to robodoc.rc, just add ${CMAKE_SOURCE_DIR}/ to the front of the file name.

Unit tests fail when compiled with GFortran

I suspect this is an issue regarding default edit descriptors * of ifort vs gfortran, but haven’t investigated.

Example 8 failing on gfortran 4.9.2

Just noticed that Example 8 (Valid test 2) is not giving the correct output when compiled with gfortran 4.9.2. I think it is a compiler bug, since it works on gfortran 5 and ifort. Will look into it. Maybe there is a simple workaround. The error message is odd also, since it is encountering a ! character, which isn't in the string:

Error in parse_object: Expecting end of object: !
line: 5, character: 1
}
^

This is one of the examples where the json structure is read from a string.

Better real number printing

When using json_print, consider a more flexible output format for doubles (for example zero should be printed as 0.0 rather than 0.0000000000000000E+000).

Upload ROBODoc documentation to gh-pages project page

This is just a suggestion, but it might be nice to have the ROBODoc documentation online. The README.md could then link to the API documentation. I’m going to work on a feature branch to implement this in the CMake (and maybe build.sh) builds if you like the idea. I’ll send a pull request when I’m done.

I’m not sure whether or not it would make sense to also add something like a “publish” target (which would not be triggered with the “all” target) to automate publishing to gh-pages. To do this git commit and git push commands would have to be issued. CMake has machinery to find git, and script this in a makefile. However, having something like:

git clone [email protected]:jacobwilliams/json-fortran.git -b gh-pages ${CMAKE_CURRENT_BINARY_DIR}/documentation
cp -r ${CMAKE_CURRENT_BINARY_DIR}/doc_build/* ${CMAKE_CURRENT_BINARY_DIR}/documentation/
cd ${CMAKE_CURRENT_BINARY_DIR}/documentation
git commit --all -m “Automatically publishing ROBODoc generated documentation”
git push origin gh-pages
cd ..

but it does make me a bit nervous to be scripting git commits and pushes to remotes. One could also argue that it is less likely to make a typo if it is scripted and tested.

Since scripting the publishing of gh-pages with the build system is of no utility to end users I think it doesn’t make sense to include it.

Check out this page on GitHub help for some info on creating a project page.

Module name change

I'm thinking of changing the module name from json_module to jsonfortran (and the file to jsonfortran.f90). This is just so they are consistent with the project name. It will break backward compatibility, but I've already done that anyway with recent reorganization, so it shouldn't be a big deal. Once this is done, the API should be pretty stable from here on, since I'm pretty happy with the all the nomenclature now.

test the stand alone programs listed in the README.md

I’m thinking of adding a few lines to build.sh that will pull out an fortran program source listings in the README.md and dump them into src/tests/jf_test_<program_name>.f90 to get compiled and run with the other unit tests. This would mean that the full programs listed in the README.md could be tested to ensure that they at least compile and run, without having to maintain duplicate copies of the source code. If they get moved to a wiki, as suggested in #66, however, I think we will lose the ability to do this. Thoughts?

get and get … vec discrepancy with dummy argument attributes for path

I noticed that a number of subroutines, like json_get_integer and json_get_integer_vec have a discrepancy when it comes to the path argument. For the scalar version, path is an optional argument, whereas for the vector version path is a mandatory argument…

This may not be a bug at all, but I was wondering if you could help me understand the discrepancy.. Looking at json_get_array it looks like the get_…_vec routines should have the path as an optional argument…

Runtime speed improvements

Need to do some speed tests, and also see if there are any changes that can be made to speed up the code. The file reading and/or parsing seems rather slow. See also #37.

white space cleanup

So, perhaps I’m a bit OCD, but the line endings are making me a bit crazy. I’m going to submit a pull request with a white space clean-up. You’re welcome to reject it if you don’t think it adds anything. I can also post some git hooks/git filters to help keep white space issues out of the project.

CMake build

I want to make sure @jacobwilliams is amenable to moving to a CMake based build system before I start work. Just give me a 👍 and I'll get cracking and then send a pull request with the implementation once I have implemented it.

CMake outputs of ROBODoc must be specified in CMakeLists.txt manually

Problem

This is a pain, because if a new source file is added, or the ROBODoc build flags are changed, or a documentation header is changed, this could change which files are output.

Solution

All information needed to determine this is present at configure time, so it should be possible to determine the outputs and store them in a list, rather than specifying them manually.

I will try to sneak this into the pull request I have open, #16

Read JSON from a character string

Would like to expand this library to also include the ability to read a JSON structure from a character string (currently, we can only read from a file).

Fix Indention

When using json_print, the indention isn't being done correctly sometimes for objects that are contained within other objects.

CI?

I’ve just started learning how to use Travis CI, and setting something up for this project wouldn’t be too bad. Once #27 and #30 are resolved we could add the tests to the CI system… I hope to get to them soon, btw, sorry for the delay. We could then add a fancy travis-ci build status badge to the homepage. The build could only be tested with gfortran, AFAICT, but it could be tested on Linux and Mac, and using all of the build systems.

Alternative to using array constructor for writing array to JSON?

Hi all,

I was just wondering if there was an alternative way of being able to write an array, as I am working with a derived-type variable string array; I'm having a hard time writing using the array constructor directly, without writing to a fixed-length char array.

Here is my distilled version of the kind of thing I'm currently doing, which works with gfortran 4.9.2:

    ! the kind of data structure I'm working with
    type string
      character(len=:), allocatable :: str
    end type string
    type(string),  dimension(:), allocatable :: derived_type_array

    ! put data in derived_type_array
    ...

    character(len=20), allocatable :: strarr(:)
    ! workaround to get string array output to JSON , I picked 20 as it was suitable for my needs
    allocate(strarr(size(derived_type_array)))
    do i=1,size(derived_type_array)
      strarr(i) = derived_type_array(i)%str
    end do
    call json_add(outp, 'char_array', [(strarr(i),i=1,size(derived_type_array))] )

    ! more stuff related to closing the JSON pointer / file
    ...

When I don't performed the strarr assignment via fixed-length char arrays, I get empty strings in the JSON output array.

How can I avoid doing this? My only thought was maybe having a method to perform scalar writes to an array, to avoid the above workaround. I also have not tried another Fortran compiler (yet). It's been such a long time for me to work with character arrays, so maybe I'm just trying too hard, and there is an alternative array add example? If there is more interest, I could improve this up to minimal working example. At the very least maybe I can contribute a unit test.

Again, I'm very appreciative of the source code! This has really envigorated my re-learning of the latest standard, and made Fortran so much easier to interface with regards to file I/O ease.

differentiate internal (low level, private) procedures/types/etc from public API in documentation

For example the json_data_non_polymorphic derived type is not public, and needn’t be documented in a user manual, only a project programmer’s manual.

The change is simple, just add an i in front of the header type, e.g., !****c* json_module/json_data_non_polymorphic ➡️ !****ic* json_module/json_data_non_polymorphic

Then, a CMake option, defaulting to no internals, could be used to control if internals are included in the ROBODoc documentation.

invalid json input files (test1.json, test5.json)

I will submit a pull request shortly as I have fixed the following issues (found by jsonlint):

1. invalid 4 hexadecimal digits (XXXX) following \u in test1.json
2. On lines 19, 26 decimal numbers end with a . without a following digit of test5.json
3. spurious comma in test5.json on line 59

I’m unsure if these fixes have any implications for the correct functionality of libjsonfortran.

CMake produced Visual Studio Project

Figure out if we can use CMake to automatically generate a Visual Studio project. If so, provide some instructions on how to do it, and remove the VS project currently there.

Enabling support for gcc 4.8

I like the idea of using the latest compiler and all new stuff, but there are a lot of Linux distributions that hold back a little bit and for instance support gcc 4.8 or even 4.7, when I try to compile the package in my Ubuntu Linux with gcc 4.8 this are the missing features:

➜  build git:(master) ✗ make
Scanning dependencies of target jsonfortran
[ 25%] Building Fortran object CMakeFiles/jsonfortran.dir/src/json_module.f90.o
/home/oscar/Projects/json-fortran/src/json_module.f90:168.44:

        character(len=:),allocatable :: name
                                            1
Error: Deferred-length character component 'name' at (1) is not yet supported
/home/oscar/Projects/json-fortran/src/json_module.f90:145.56:

            character(len=:),allocatable    :: str_value
                                                        1
Error: Deferred-length character component 'str_value' at (1) is not yet supported
/home/oscar/Projects/json-fortran/src/json_module.f90:145.56:

            character(len=:),allocatable    :: str_value
                                                        1
Error: Deferred-length character component 'str_value' at (1) is not yet supported
/home/oscar/Projects/json-fortran/src/json_module.f90:145.56:

            character(len=:),allocatable    :: str_value
                                                        1
Error: Deferred-length character component 'str_value' at (1) is not yet supported
/home/oscar/Projects/json-fortran/src/json_module.f90:3614.30:

        call me%data%destroy()
                              1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:3581.30:

        call me%data%destroy()
                              1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:3548.30:

        call me%data%destroy()
                              1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:3510.30:

        call me%data%destroy()
                              1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:3470.30:

        call me%data%destroy()
                              1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:3430.30:

        call me%data%destroy()
                              1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:3390.30:

        call me%data%destroy()
                              1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:1086.32:

        call this%data%destroy()
                                1
Error: 'destroy' at (1) should be a SUBROUTINE
/home/oscar/Projects/json-fortran/src/json_module.f90:168.44:

        character(len=:),allocatable :: name
                                            1
Error: Deferred-length character component 'name' at (1) is not yet supported
/home/oscar/Projects/json-fortran/src/json_module.f90:145.56:

            character(len=:),allocatable    :: str_value
                                                        1
Error: Deferred-length character component 'str_value' at (1) is not yet supported
make[2]: *** [CMakeFiles/jsonfortran.dir/src/json_module.f90.o] Error 1
make[1]: *** [CMakeFiles/jsonfortran.dir/all] Error 2
make: *** [all] Error 2
➜  build git:(master) ✗ gfortran --version
GNU Fortran (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

my compiler notices the missing features, that implies that they maybe implemented
in the 4.8 version, perhaps they can be enabled adding a flag to the command
that can be easily done with cmake, I'm not much of a fortran programer,
so I'm not familiar with gfortran compilation flags.

small memory leak

While testing some of my own code for memory problems using valgrind, I came across a small memory leak in json-fortran. It's truly small -- 1 byte. But I'm trying to make everything neat and tidy, so....

The leak can be seen by compiling the example under the header "Writing a JSON file" in the json-fortran README.md file. I am using gfortran 4.9.2 on Ubuntu 14.04.

Running valgrind as

  valgrind --track-origins=yes --leak-check=full --show-leak-kinds=all ./example2

traces the leak to the first call to json_initialize and then to

https://github.com/jacobwilliams/json-fortran/blob/master/src/json_module.f90#L920

The leak can be "fixed" by replacing the call to json_clear_exceptions() at line 889 with

    exception_thrown = .false.

that is, the leak is fixed by not setting

    err_message = ''

in the first call to json_initialize.

Making this change has no obvious, detrimental impact on the example from the README.md file or on the example program that gets build when json-fortran is built. (The same is true for my code 😃 )

Finally, gfortran's -g flag is handy. Without it, I would never have tracked down the problem. You might consider using it in build.sh.

Broke

I seem to have broke something with my last commit. The cmake and visual studio directories are no longer there. Will try to fix.

libjson common name

Performing a search for libjson returns a lot of results. I think that the library we build using CMake or build.sh should have a more unique name, so that C/C++ etc. json libraries can be installed in parallel without ambiguity.

Might I suggest libforjson as the library name? Thoughts @jacobwilliams ?

more graceful behavior when ROBODoc missing with CMake

I’m currently working on #42, specifically setting up a build matrix to ensure that the library builds with all 3 build methods, and think that the CMake build should be “just do what I want” a little bit more, “Fortran poor man” style when ROBODoc is missing. Currently there is a variable that can turn off ROBODoc, but if ROBODoc is turned on, but CMake can’t find the ROBODoc program, the configuration halts. Instead I think most people would prefer a warning, and then continuing the config/build without making the documentation. Should have a PR shortly with this and the travis-ci build matrix.

Thread Safety

Currently the module is not thread safe (due to the global variables used when parsing a file and to manage the error conditions). Consider refactoring the code to make it thread safe.

Stack overflow in destroy for large structure

Stack overflows can occur in json_value_destroy for very large structures. @acroucher has a solution for this in fson. I'll see if that fixes the problem.

Unaligned data warnings with Intel compiler

Commit 0066f7d (where a SEQUENCE attribute was added to json_value type) is causing unaligned data warnings to be issued by the Intel fortran compiler (v2015). A fix is in the works.

Wiki documentation

Consider moving some of the how-to information from the README.md file to the Wiki and expanding. For example, to cover a lot of different sorts of use cases, explain subtle details, avoiding memory leaks, etc.

wiki contribution issues

Could you check the repository settings, especially the wiki settings? I tried to contribute some changes but am having trouble. It could be an issue with github, too. Read up about how to check the wiki permissions here

build.sh failing with ifort

On OS X Yosemite, with

$ ifort -v
ifort version 15.0.2

if I set use_ifort=1 in build.sh the build fails with this output: https://gist.github.com/zbeekman/d89663e5c9669217ed0c

I’m not sure if this is an issue with @szaghi’s FoBiS.py or an issue with @jacobwilliams’ build.sh

Could use class(*) to simplify code

Some of the procedures could be consolidated if I made use of class(*) arguments. However, I've found that support for this is buggy among the compilers. If there comes a time when it works reliably on at least ifort and gfortran, I may update the code. Currently, will leave as is.

Public APIs for creating a JSON structure

Consider removing the necessity of having to use pointers to construct a JSON structure for writing. This could be done by encapsulating the pointer inside a class (as was done for json_file).

Add CONTRIBUTING.md with contributing guidelines

Having a CONTRIBUTING.md file is nice because it will help give others clear guidance on how to contribute to the project, what the coding standards are, etc. When someone opens a new issue, github will automatically put a link above the new issue urging the person to read the contributing guidelines…

Coverage info

Once #30 and #27 are wrapped up, it would be nice to get test coverage info, and maybe use coveralls. I think this should be straight forwards to setup, using the C/C++ example/howto. I doubt any changes need to be made for Fortran.

Unit tests

Need some rigorous unit tests.

CMake build using makefiles fails if parallel build is specified

I think this is due to the fact that a statically linked library and a dynamically linked library are built at the same time. Perhaps it would make sense to either:

1. Take steps to ensure that the makefile produced disallows parallel builds (but I’m not sure how to do this in CMake) or…
2. Have a cache variable that allows the user to select whether a static library or a dylib/so/dll is built

I’ll try to look into this further.

build tools

Gentlemen,

In the project for which I am using json-fortran, I have chosen to use SCons as the build system.

I find that the build.sh file works just fine, but it's a little too simple for purposes. I have no problem with CMake, but as written the CMake files for json-fortran have a requirement on jsonlint (there are many things called jsonlint, you seem to be using this one, right?), which, in turn, requires that node.js be installed. node.js is supercool, but not something I want to impose upon my users.

Here (https://gist.github.com/bruceravel/c74dd55c5a33a6966437) is the SConstruct file that I came up with. It very closely emulates the behavior of the build.sh script, but with logic for dependencies, cleaning, and installing.

If you think that others might appreciate this, then you can drop it in the top directory under the name SConstruct. With it in place (and with SCons installed), the library is built by typing scons and installed by scons install or sudo scons install. I can also imply leave the gist in place for linking to.

If you would rather not have a proliferation of build tools in the repo, I completely understand.

Regardless, I am grateful for json-fortran. It has really filled a need in my work. 😃