| Age | Commit message (Collapse) | Author |
|---|
|
Re-arranged the code. Will add amendments to manifest created by
--full option shortly.
Any other discussions still open?
|
|
Group sources by package in the model
|
|
|
|
|
|
|
|
Co-authored-by: Sebastian Ehlert <28669218+awvwgk@users.noreply.github.com>
|
|
Initial implementation of `fpm build --show-model`
|
|
|
|
|
|
|
|
It is not needed at the moment, but it will have to be put back in once
we extract str() into a dedicated string manipulation library (or
stdlib).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to add the kitchen sink
Simplified the defaults to be able to use auto-discovery and the simplest
manifest (fpm.toml) file but at the same time provide an easy way to
get a fully populated default structure (ie. one that adds the example/
directory) and also provides a heavily annotated manifest that helps with
understanding how to create a more complex project and also understanding
how your simple project can grow beyond a basic default package (one of
the first questions someone will have even if they are not ready to use
it all is will using `fpm` be too restrictive?)
|
|
|
|
|
|
Also changed the sample program to demo.f90 and the test directory to
check.f90 so if they are added with --backfill that reasonable names are
created without modifying the manifest file (fpm.toml) so they can will
still be built with auto-discovery reasonably. Note test/check.f90 was
used instead of test/test.f90 because any program called "test" on ULS
platforms is very problematic.
After having a few users without `fpm` experience try it, they seem to
be looking more for a template to choose and tools to help move existing
projects to fpm (or move fpm to work more with existing projects) than
what "new" currently does. I think this will change as more programs
originate with fpm instead of needing to be moved to it, but instead
of having "new" do everything having templates like some of the samples
already available pulled down, possibly even with an interactive interface
seems like a better long-term direction.
|
|
Remove: -ffast-math in gfortran default release flags
|
|
|
|
directory
The "new" subcommand was updated with an --example switch in line with the other
standard directories. Corresponding changes were made to the documentation and
the test of the "new" subcommand. This reflexs the addition of --example to the
"run" subcommand and the model changes to automatically build applications found
in the example/ directory.
|
|
|
|
Fix: program object file collision
|
|
Implement fpm-install command
|
|
|
|
|
|
|
|
Use a separate example subdirectory in 'build' to store example executables.
|
|
|
|
Simplify object naming rules to avoid issue where programs in different top-level folders can have the same object file name. Fixes #305
|
|
|
|
Add: support for detecting .f and .F files
|
|
Co-authored-by: Milan Curcic <caomaco@gmail.com>
|
|
Add support for same compilers as Fortran version to Haskell version
|
|
|
|
|
|
Fixes to source parsing
|
|
Remove note on not supported dependencies in program targets
|
|
|
|
Remove -coarray=single option from ifort compiler default options
|
|
Targets not generated for empty source files
|
|
Fixes issue where assignment statements with variables called 'program' and 'module' are detected as program and module declaration statements.
|
|
With the intel compiler ifort(1) use of the -coarray=single creates
an executable with images instead of just allowing the coarray
syntax as with the GNU gfortran compiler so it is being removed as
a default option and will be implemented via a more general option
allowing for user-specified compiler options. As it is, use of the
option requires developer platforms to support auxiliary libraries
not always available, and coarray does not appear to be on all
platforms supported by ifort (e.g. MacOS).
2020-12-11
|
|
|
|
|
|
- update documentation to include default settings
|
