On Thu, 31 Mar 2011, Darius Blaszyk wrote:
On Mar 30, 2011, at 11:46 PM, Michael Van Canneyt wrote:
fpmake build debug
I would prefer a named option, i.e.
fpmake build --profile=debug
from the users perspective this is not very friendly.
It is more clear what is meant. All other options are also specified with a
--option
I won't make a fuss about this as it's also a matter of taste. More important
is the functionality itself.
Exactly :-)
and I think TDefaults.Profile needs to be a) A collection.
b) Loadable from some config file, I suppose ?
--profile then just selects one item in the collection.
So you mean have a fpmake.pp and next to that a fpmake.cfg?
Not next to it, on a central location on your system.
Rationale:
I imagine that one wants to have some often-used profiles on a central location.
These will be machine specific:
debug
profiling
testing
if you download a package and compile it, you'd have to edit the fpmake.pp
and add these profiles each time. If the profiles are in a ~/.fpmake
file, which is loaded on start, then you need to define the profiles only once,
and they will be available for all packages you wish to compile.
One remark, with your reasoning, all packages will support each defined
profile. This is not necessarily the case, also for FPC. You could even
argue quite the opposite, but as long as you have comprehensive messaging
it should not be a problem, although it will generate quite some "false"
errors on building.
I think it highly depends on what you will put in the profile.
Standard profiles such as debug and release profiles will probably
simply have some -gl -vw -dDebug or -Ur and -O2 options, which are
understood by all projects.
if your projects profiles need more specific defines or options,
then they must obviously be code in code.
That does not make sense. The fpmake.pp in itself is a config file (well sort
of). I would just prefer to keep it simple, maybe have the user register the
profiles in fpmake.pp?
See above for the rationale. But obviously, they must be definable in code as
well.
I see the above as an add-on to manual definition only.
As long as it's possible to register profiles in a fpmake file itself, I'm
fine. For a standalone project this makes more sense. Imagine you have
debug, profiling and testing setup locally but the project adds
"profiling" as a build profile. Then fpmake would not recognize it (and
raise some sort of error message because it's an invalid profile) until
you added it yourself to the local config. So having both options is best
here.
Agreed.
I would definitely load profiles from file only after all user profiles
are made, and would not load something again that the user already defined in
code.
Like I said: an add-on to manual definition only...
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
