[fpc-devel] fpmake patch 21-aug

[Michael Van Canneyt]

On Tue, 21 Aug 2007, Michael Van Canneyt wrote:

> 
> 
> On Tue, 21 Aug 2007, Darius Blaszijk wrote:
> 
> > The following patch implements:
> > - added EXTERNALZIP define to make bootstrapping possible (missing zipper
> > unit)
> > - implemented SearchFiles method which can search recursively and with a
> > filemask (asterisk or questionmark) using MatchesMask function
> > - implemented methods AddDocFiles, AddSrcFiles, AddExampleFiles, AddTestFiles
> > in TCustomInstaller
> > - implemented archiving of all files in TSources
> > 
> > Although the patch produces valid code, I also discovered some caveats in the
> > process that need to be addressed. When using the fpmake.inc construct as in
> > fcl\packages, a problem with the base directory arises. A package is written
> > in such a way that files belonging to a package are described by using
> > relative paths. This works as long as you create a fpmake.pp file per package.
> > When using the .inc approach, all code is linked to the top level fpmake.pp
> > file, which destroys the paradigm. The only thing I can come up with is make
> > an ifdef per fpmake.inc (which is very ugly imho) or not to use this approach
> > and make it possible to cascade fpmake invocations starting from the top level
> > fpmake. Any thoughts?
> 
> This problem has been considered when implementing the fpmake.inc.
> 
> The ifdef with the directory name is already there. 
> This should give you a hint as to the path that was taken then :-)
> 
> The idea was that a single fpmake could be used to install all FPC-distributed 
> packages. By making it a single fpmake, the build process will automatically
> take care of ordering. If you make it multiple fpmake files, then you must still
> add some extra fpmake which 'glues' things together in the correct order; but then
> the ordering must be done manually, and you need to add additional communication
> between fpmakes. Quite tricky.
> 
> The current approach worked fine, so I don't see what the problem is ?

Forgot to say that I implemented the patch, obviously.
I think the 'MatchesMask' function belongs in strutils or sysutils.
(a copy of it exists there anyway :/)

Michael.