[fpc-devel] fpmake patch 21-aug

[Darius Blaszijk]

Michael Van Canneyt wrote:
> 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 ?
>>     
There's no real problem. I proposed two alternatives from which the 
first one was chosen. I hadn't given much thought to this issue until I 
implemented the archive command.

> 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 :/)
>   
Sure? I searched the rtl and couldn't find the function. I agree it 
should live there, but afaict it doesn't yet. I found the code in 
fpunit.pp which was used in the fpc ide iirc. I modified it Can I make a 
patch to move the function to StrUtils or will you do it (don't forget 
documentation update)?

Darius