[fpc-devel] The future of fpmake
Joost van der Sluis
joost at cnoc.nl
Thu Mar 31 17:37:42 CEST 2011
On Wed, 2011-03-30 at 17:09 +0200, Darius Blaszyk wrote:
> A couple of things that come to mind:
Note that you can build your own add-ins. I used it to build a
Lazarus-add-in, so that you can install Lazarus-components. It is not
ideal yet, but you can use this approach to add functionality, without
having to adapt fpmkunit.pp.
> - generation of documentation (fpdoc and possible other??)
> - compilation of example files
> - compilation and running of the testsuite
> - generation of the classchart
> - execute fpmake from command line (see thread by mattias : "run pascal programs as script") for this we would need instantfpc to support win32 and it should be supplied as a standard fpc tool
> - implement the creation of installer (scripts) for all platforms
> - implement a binary zip option
> - managing debug/release builds (also cross-compiling)
> - cmake like system (display and store information on builds and test suites, etc)
Some of these ideas are long standing items on the wish-list. And what I
miss is Lazarus-integration. In which we have to decide if we want to
create some units that can be used by Lazarus, or a library that can be
called...
But if you want a/my road-map:
1: Let the fpc-installers create fppkg configuration files (almost done,
needs a lot of testing)
2: Build some packages from fpc itself with fpmake in trunk. Use it as a
field-test. (testing that locally, I wanted to commit it last week but
I've found a new issue, probably in trunk very soon)
3: Improvement of version-handling
4: Multi-threading
I still want to try to use fpmake to build the packages of fpc 2.6.0.
> Of course these are all nice to haves, but agreeing what is in and what definitely not does not hurt. All "out of scope" functionality could be added to an external fmkextunit.
Indeed, as add-ins.
Joost.
More information about the fpc-devel
mailing list