For already existing projects you will need to define a fpm.toml with all the location of your source files. That might not necessarily play nice with your existing project structure.
You might want to have a look at one of my open source repos that takes an existing repo and repackages it for fpm
If you have your source files under src it’s probably going to be a lot easier to build with fpm. The thing that you will probably miss is defining a set of compile flags, but we are in the process of getting that working in a future release.
In many cases I start with “fpm new DIRNAME” or “fpm new . --backfill” in an existing directory. Without seeing your original file structure I am not positive that is better than manually creating the subdirectories, etc. I have found it simplest in most cases to start that way. I am curious why you did not use “fpm new” as it might point towards ways to improve that subcommand.
--profile PROF selects the compilation profile for the build.
Currently available profiles are "release" for
high optimization and "debug" for full debug options.
If --flag is not specified the "debug" flags are the
default.
(For fpm developers, should the --flag in the last sentence of the description be --profile?)
It’s correct but a little confusing. If --flag is specified no profile is applied unless specified. This allows you complete control of the compiler options. If --flag is not specified the default is --profile debug.
So if --flag is specified and no profile is specified only the options specified with --flag are applied.
If both are specified the options from the profile are combined with the options specified with --flag.
fpm run ### same as "fpm run --profile debug"
fpm run --flag '-Wall -O3' ## only the options specified are applied
fpm run --flag "-march=broadwell" --profile release # use options from release profile plus specified option.