Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2007-08

fpmake patch 21-aug

6 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Darius Blaszijk

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?

Darius

Reply by email

Michael Van Canneyt
to Darius Blaszijk
Darius Blaszijk wrote 19 lines
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 ?

Michael.

Reply by email

Michael Van Canneyt
to Michael Van Canneyt
Michael Van Canneyt wrote 37 lines
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.

Reply by email

Darius Blaszijk
to Michael Van Canneyt
Michael Van Canneyt wrote 40 lines
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

Reply by email

Luiz Americo Pereira Camara
to Darius Blaszijk
Darius Blaszijk wrote 9 lines
> > 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)?

Are you looking for StrUtils.IsWild?

Luiz

Reply by email