Feature/fortran #96
Open
Feature/fortran #96
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Handwritten (for now) C-language interface for some of the classes. For our purposes here, simple compilation scripts and examples.
Work in progress.
Very tedious, but coming along.
Small name changes.
Basically, that was for consistency. Did a bit of reformatting in json2class.cpp.
Small changes in a couple of scripts.
nameClass() doesn't use any "name" override in a key's value, but always uses the key itself.
In preparation for putting together a GNDS 2.0 interface, I wanted to improve the way in which current content was organized. We had "prototype" GNDS 1.9 input specs in the autogen directory. However, calling it even a "prototype" was a bit much, because it had so little of the actual, full GNDS 1.9 specification. More accurately, it was simply an example of using the code generator. It wasn't even close to being GNDS 1.9. The code generator's inputs for this "prototype" were placing "v1.9" content into GNDStk/python/src and GNDStk/src/v1.9. That is, the content was going into the GNDStk repo's root directory. Given that this thing isn't really GNDS 1.9 by any stretch of the imagination, that output never really belonged in the root directory. Rather, it belonged in the autogen directory, under prototype. So, I moved the appropriate content to where I believe it belongs. Note that the general core-interface material (source and tests) remains in GNDStk/python. Only the not-really-"v1.9" files were moved. Various CMake-related files as well as C++ files were updated to reflect the move. How, precisely, we'll arrange GNDS 2.0 and GNDS [future-version] material is to be determined. @whaeck's dev/gnds-2.0 has them in GNDStk/standards, which I think is a good place. For the code that we'll generator for GNDS 2.0, etc., I'd say that we should remain in that directory structure, rather that going upwards to the main GNDStk/ directory as we originally did with the prototype.
…y_abstract on NEA Gitlab.
…type-rearrangement
Accounting for both Wim's changes and the current (2022-aug-23) master branch at git.oecd-nea.org I'm putting back in the nodes that create "circularity" issues, so that I can identify precisely where it happens, and fix it properly. This is all currently a work in progress!
Small coloring change in utility. Added some files to to-process list in gnds-2.0 json spec.
Not really important, but noticed it while working with v2.0.
Minor style modifications, to be consistent with other code.
The new hierarchy and the file locations are better.
Previously, that had been handwritten. And, perviously, it was in the wrong place. (This was fixed already.) Removed unnecessary semicolons after certain autogenerated *functions*. We need semicolons for classes, of course, but for functions they're meaningless.
This is part of a broader reorganization. Previously, we'd put various GNDS-related enumerators, e.g. Interpolation, into the main GNDStk code. I.e., essentially into the Core Interface. Such enumerators are actually GNDS version-dependent, however. It's possible that they won't change across versions, or that some enumerators will, at least, be common across versions. However, in principle, enumerators *are* version dependent. So, I decided that they should be given in the version-specific code. At the moment, we only have GNDS 2.0 as a particular version. So, I put the enumerators there. This move required, at least for the time being, that I connected certain test codes with the GNDS 2.0 code, just to get the enums that those test codes used - enums that previously arrived automatically from the Core Interface. In particular, I needed to do this with the material in autogen/prototype. This code was generated by the code generator quite a while back, but is still used for some tests related to the Component interface. Eventually, code at a "lower level" than GNDS 2.0 shouldn't need to tie in with the GNDS 2.0-specific code just to get enumerators they need! Rather, such things should have their own enumerators if they need them. Linking them with GNDS 2.0 code is intended to be a temporary measure, to get all the tests compiling and running after having moved the enumerators. Which, as described above, was really the right thing to do. Remark. The version-specific enumerators are written in a very mechanical manner. Eventually, I should simply have the code generator take some additional input regarding what enumerators a specific GNDS version needs, and then generate the enumerator files! This isn't a priority at the moment, but it's worth mentioning.
At least, it accepts enumerator names, but doesn't fully deal with enumerator values yet. Accepting enumerator names allowed us to fully autogenerate other codes that needed, for example, to #include or wrap (for Python) the enumerators. Fully handling individual values (in a given enum class) is slated for the future. In this way, we'll be able to generate code that are currently handwritten in GNDStk/versions/GNDS-v2.0/GNDS/src/GNDS/v2.0/enums/.
Uploading work done earlier this week.
Not quite functional yet. Added so we can track changes.
Note: re-autogenerated C++ files in prototype/ break the build right now. So, I'm not committing them right now. This has something to do with enums having been moved from njoy::GNDStk:: to specific code-generation places (an earlier change, and done for good reasons). I need to soup in prototype/ material to have the requisite enums directly, but may or may not have time for that right now.
A bit of reformatting as well.
Small changes with some autogenerated C functions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Automatic generation of Fortran bindings.