-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fortran fpm] Internal dependencies & build backend #155
[Fortran fpm] Internal dependencies & build backend #155
Conversation
Create separate modules for filesystem and string routines. These can be substituted eventually for stdlib.
Currently extract use/include dependencies and resolves these to specific source files. Also included lower and split string routines as needed.
C programs (int main) not yet allowed.
Thanks a lot Laurence. I only did a cursory read through for now and have a few suggestions:
|
Thanks for the comments @milancurcic! I agree with you on all points. |
This is a great start, and a great next step. Thanks @LKedward . I agree with @milancurcic for I will try and find time over the next few days to try and look into the CI failures a bit more closely and see what's going on. |
Great work! Thank you.
Where is the fpm_model module? I couldn't find it (on my phone).
…On Wed, Aug 26, 2020, at 9:14 AM, Laurence Kedward wrote:
Opening a draft PR for feedback.
Implements:
* a rudimentary process for scanning sources and determining
inter-module dependencies.
* a simple fpm backend for building files in correct order
This is really a minimal working implementation, many places for
improvement (particularly source parsing),
but it should now build any stand-alone package that only uses the
`src` and `app` directories (no subdirectories).
A nice example: fortran `fpm` can now build itself. Run `fpm run --args
'build'` with Haskell `fpm`.
Other changes:
* Moved filesystem and string routines into separate modules for now -
these will eventually be substituted by stdlib routines.
Not yet implemented:
* non-default layouts (requires `fpm.toml`)
* fpm model structure
* Package layout constraints
* Library archiving
* Incremental builds
* Build output directory
Tested on Ubuntu Linux (gcc-7.5.0) and MinGW Windows (gcc-8.1.0).
You can view, comment on, or merge this pull request online at:
#155
Commit Summary
* Restructure: move some routines out of fpm module.
* Use temporary file for directory listing output.
* Minor fix: to read_lines subroutine.
* Add: Sourcefiles module for processing sources.
* Minor fix: to count_rows in filesystem mod.
* Add: initial fpm build backend.
* Add: initial support for c sources.
* Minor fix: add dependency pointer guard.
File Changes
* *A* fpm/src/FPM_Backend.f90
<https://github.com/fortran-lang/fpm/pull/155/files#diff-475cc582fa5d31afd70a27d7efa178df> (49)
* *A* fpm/src/FPM_Filesystem.f90
<https://github.com/fortran-lang/fpm/pull/155/files#diff-051a34076927ef0e96a561c89801de72> (125)
* *A* fpm/src/FPM_Sourcefiles.f90
<https://github.com/fortran-lang/fpm/pull/155/files#diff-7e8ed2fd5212f618126c139653c2f364> (375)
* *A* fpm/src/FPM_Strings.f90
<https://github.com/fortran-lang/fpm/pull/155/files#diff-e1790889afd1b0c2e62f82231394fa23> (195)
* *M* fpm/src/environment.f90
<https://github.com/fortran-lang/fpm/pull/155/files#diff-32b40b492690c8c8294e981a0fb78e70> (14)
* *M* fpm/src/fpm.f90
<https://github.com/fortran-lang/fpm/pull/155/files#diff-e235e41ae1a801d1ff11bfa3aa1ea6db> (134)
Patch Links:
* https://github.com/fortran-lang/fpm/pull/155.patch
* https://github.com/fortran-lang/fpm/pull/155.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#155>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAFAWH4WICQDIJWIZZH6DDSCURF5ANCNFSM4QL6FSFA>.
|
Yep, @certik is correct. It looks like the |
That was the most important module I wanted to look at. ;)
…On Wed, Aug 26, 2020, at 7:59 PM, Brad Richardson wrote:
Yep, @certik <https://github.com/certik> is correct. It looks like the
`fpm_model` module got missed with the commits
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#155 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAFAWH7POTCLAX6LUPAVHDSCW4Z7ANCNFSM4QL6FSFA>.
|
Sorry yes, I'll push an update later that works with an initial I don't mind use |
Backend now only accepts the fpm model structure. This structure currently only contains the array of sources.
@LKedward do you want to finish this PR, so that others can build upon it once it is merged? |
Ignores ancestor name in submodule declaration statement.
Adds output directory, compiler and compiler flags to model structure - currently hard-coded values. Adds mkdir subroutine in filesystem, implemented via command line shell.
I've added Currently having issues building with Haskell If necessary, I'm happy to rebase this PR after #157 is merged. |
manifest and model sources files were incorrectly using Windows EOL.
…ly declare public names
I reviewed in more detail and I think this is good to go. I also made the following changes:
There are no semantic changes to the code. |
Many thanks Milan! I'll be sure to follow those guidelines in future. |
@LKedward I don't think we even had these in the style guide but I think we should. |
Fortran fpm can now build 'hello_complex' example
I've now successfully merged in the recent changes so that fortran |
Output of split (M_strings) needs trimming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just looked briefly over the code, I will try to test it more extensively soon. Here is what I got so far.
Adds string_array_contains helper function for determining if array of string_t contains a particular string.
@LKedward I did a bit of further testing and actually trying to break the implementation, see #167, the report is regarding bootstrap fpm but is also not working well with this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mainly care about the fpm_model
file, as everything else can be refactored later.
I left some comments there.
This is a great start, and we will be able to take it from here.
fpm/src/fpm_model.f90
Outdated
|
||
contains | ||
|
||
subroutine build_model(model, settings, package) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function should got to the "front-end". The fpm_model
file should only contain the model itself, not how to construct it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Essentially the model should be completely standalone, independent of the front end. That way, any backend that we have just takes the model as the "input", and does not have to worry about anything else. The backends should not worry about the command line, or any kind of "user settings". The front end takes user settings and populates the model.
type :: fpm_model_t | ||
character(:), allocatable :: package_name | ||
! Name of package | ||
type(srcfile_t), allocatable :: sources(:) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The srcfile_t
derived type should be defined in this file.
use fpm_manifest_executable, only: executable_t | ||
use fpm_sources, only: resolve_module_dependencies, add_sources_from_dir, & | ||
add_executable_sources, srcfile_t | ||
use fpm_strings, only: string_t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of these should be imported here, except string_t
if we use it in the model derived types (we do not seem to currently).
Thanks for the review @certik, I've implemented your suggestions for isolating the model definition from the frontend. |
Thanks. Looks good now. +1 to merge
…On Fri, Sep 11, 2020, at 9:38 AM, Laurence Kedward wrote:
Thanks for the review @certik <https://github.com/certik>, I've
implemented your suggestions for isolating the model definition from
the frontend.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#155 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAFAWHWQ4NDOV6BSDJ35ETSFJAAFANCNFSM4QL6FSFA>.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me as well.
@everythingfunctional Please merge when ready, in case you're still reviewing. |
Opening a draft PR for feedback.
Implements:
This is really a minimal working implementation, many places for improvement (particularly source parsing),
but it should now build any stand-alone package that only uses the
src
andapp
directories (no subdirectories).A nice example: fortran
fpm
can now build itself. Runfpm run --args 'build'
with Haskellfpm
.Other changes:
Not yet implemented:
fpm.toml
)Tested on Ubuntu Linux (gcc-7.5.0) and MinGW Windows (gcc-8.1.0).