| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
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
|
|
- use $HOME/.local as user prefix on Unix platforms (fallback is /usr/local)
- use %APPDATA%\local as user prefix on Windows (fallback is C:\)
|
|
|
|
- abstract some platform specifics in the unit tests
|
|
|
|
|
|
- allow installing of executables
- optionally install library and modules if specified in manifest
- add install table to manifest reference
|
|
Create specification for example section and implement example applications for Fortran and Haskell version
|
|
|
|
|
|
|
|
Co-authored-by: Laurence Kedward <laurence.kedward@bristol.ac.uk>
|
|
|
|
|
|
|
|
- create a dependency tree data type with serde functionality
- allow translation from and to TOML of dependency tree
- test round trips for dependency cache
- implement iterative fetching of each dependency level
- update dependencies in fpm-update (rudimentary implementation only)
- allow removing the cache from the command line
- use dependency tree for fpm-build model
- add fpm-update to fpm-help/fpm-list output
|
|
- check within an executable/test array for duplicate programs
- also check that the program name is not empty or contains ascii control chars
|
|
Fix: missing error check after `new_package` call
|
|
|
|
Fixes silent failure due to invalid top-level manifest keys
|
|
Specify the correct help for `fpm run -h`
|
|
Document model and backend for developers
|
|
|
|
This reverts commit f049ae6d8e4bfd58a5b69d692dd7e6273fd158af.
|
