Skip to content
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

Merged
merged 31 commits into from
Sep 11, 2020
Merged

[Fortran fpm] Internal dependencies & build backend #155

merged 31 commits into from
Sep 11, 2020

Conversation

LKedward
Copy link
Member

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).

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.
@milancurcic
Copy link
Member

Thanks a lot Laurence. I only did a cursory read through for now and have a few suggestions:

  • For split() and lower() from ``M_strings by @urbanjost, should we import them as a dependency instead of in source? This would mean that fpm-fortran wouldn't be able to build itself (we can't download dependencies yet), but this seems to me like an unnecessary requirement for now. The advantage is that we have less code to maintain. Or would you prefer to keep it in source until we can download dependencies, and then replace them with use M_strings, only: lower, split?
  • FPM -> fpm everywhere (source file names and modules), as per Should we refer to this software as FPM or fpm? #77.
  • Shoud we rename module environment in environment.f90 to fpm_environment in fpm_environment.f90?

@LKedward
Copy link
Member Author

Thanks for the comments @milancurcic! I agree with you on all points.

@everythingfunctional
Copy link
Member

This is a great start, and a great next step. Thanks @LKedward .

I agree with @milancurcic for FPM -> fpm and environment -> fpm_environment. I'm also in favor of leaving lower and split in source until we can fetch and build dependencies. Since this seems to allow fpm to build itself, I think we should make efforts not to lose that ability again.

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.

@certik
Copy link
Member

certik commented Aug 27, 2020 via email

@everythingfunctional
Copy link
Member

Yep, @certik is correct. It looks like the fpm_model module got missed with the commits

@certik
Copy link
Member

certik commented Aug 27, 2020 via email

@LKedward
Copy link
Member Author

Yep, @certik is correct. It looks like the fpm_model module got missed with the commits

Sorry yes, I'll push an update later that works with an initial fpm_model structure (it only has the dependency structure in currently).

I don't mind use M_Strings as a dependency or keeping it self-contained for now - @certik do you have an opinion on this?

Backend now only accepts the fpm model structure. This structure currently only contains the array of sources.
@certik
Copy link
Member

certik commented Sep 2, 2020

@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.
@LKedward
Copy link
Member Author

LKedward commented Sep 2, 2020

I've added fpm_ prefix to all modules as discussed and implemented a minimal structure for fpm_model, currently with hard-coded values - I think this should be refined in a separate PR. For now I've left the string routines in.

Currently having issues building with Haskell fpm which is causing CI to fail, but otherwise I think this is ready for review.

If necessary, I'm happy to rebase this PR after #157 is merged.

@LKedward LKedward marked this pull request as ready for review September 2, 2020 10:58
LKedward and others added 3 commits September 2, 2020 12:06
manifest and model sources files were incorrectly using Windows EOL.
@milancurcic
Copy link
Member

I reviewed in more detail and I think this is good to go. I also made the following changes:

  • Explicit imports with use ..., only: ...
  • Explicitly list public names with the public statement
  • Remove a few unused module imports

There are no semantic changes to the code.

@LKedward
Copy link
Member Author

LKedward commented Sep 3, 2020

Many thanks Milan! I'll be sure to follow those guidelines in future.

@milancurcic
Copy link
Member

@LKedward I don't think we even had these in the style guide but I think we should.

@LKedward
Copy link
Member Author

LKedward commented Sep 7, 2020

I've now successfully merged in the recent changes so that fortran fpm can now build slightly more complex packages like the hello_complex example package. This is enough for this PR, so I won't be contributing any more of my own changes to this branch unless requested.

Copy link
Member

@awvwgk awvwgk left a 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.

fpm/src/fpm_sources.f90 Outdated Show resolved Hide resolved
fpm/src/fpm_sources.f90 Outdated Show resolved Hide resolved
fpm/src/fpm_sources.f90 Outdated Show resolved Hide resolved
fpm/src/fpm_environment.f90 Show resolved Hide resolved
fpm/src/fpm_filesystem.f90 Outdated Show resolved Hide resolved
fpm/src/fpm_sources.f90 Outdated Show resolved Hide resolved
Adds string_array_contains helper function for determining if array of string_t contains a particular string.
@LKedward
Copy link
Member Author

LKedward commented Sep 8, 2020

Many thanks for the helpful review comments @awvwgk, I've addressed all except the exit codes - am I misunderstanding you here?

@awvwgk
Copy link
Member

awvwgk commented Sep 8, 2020

@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.

Copy link
Member

@certik certik left a 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.


contains

subroutine build_model(model, settings, package)
Copy link
Member

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.

Copy link
Member

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(:)
Copy link
Member

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
Copy link
Member

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).

@LKedward
Copy link
Member Author

Thanks for the review @certik, I've implemented your suggestions for isolating the model definition from the frontend.

@certik
Copy link
Member

certik commented Sep 11, 2020 via email

Copy link
Member

@awvwgk awvwgk left a 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.

@milancurcic
Copy link
Member

@everythingfunctional Please merge when ready, in case you're still reviewing.

@everythingfunctional everythingfunctional merged commit e02171d into fortran-lang:master Sep 11, 2020
@LKedward LKedward mentioned this pull request Sep 12, 2020
@LKedward LKedward deleted the dependencies branch September 20, 2020 16:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants