Re: [fpc-devel] The future of fpmake
On Thu, 31 Mar 2011, Darius Blaszyk wrote: Imagine you have debug, profiling and testing setup locally b Should be debug, release and testing Nono, I actually meant profiling as different from debug. The difference being that debug has all optimizations off, profiling has them all on. So Release should be added to the list:-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Mar 31, 2011, at 9:22 AM, michael.vancann...@wisa.be wrote: On Thu, 31 Mar 2011, Darius Blaszyk wrote: Imagine you have debug, profiling and testing setup locally b Should be debug, release and testing Nono, I actually meant profiling as different from debug. The difference being that debug has all optimizations off, profiling has them all on. So Release should be added to the list:-) I understand, but this was a typo in the previous mail I wrote. I just corrected it as I mentioned profiling two times in the example I made. (It was rather late :) Darius___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
Darius Blaszyk schrieb: fpmake's intended use is to compile your FPC code. I can see the use of trying to run a testsuite, build docs and a binary zip for distribution: they are all FPC related things. But it is not intended as a general build system (i.e. replace make or ant or rpm or deb). What do you mean with general. Fpmake is a build system right? So why not use it also for other projects? Ok, perhaps the cdash functionality belongs in a different tool (although it could be in fpmake), but let's not limit fpmake only to FPC please. Let us (end users) also play with it ;) My view on (traditional) Make: Make is a script-driven shell, with rudimentary build-related functionality that's missing from other shells (mainly file handling). All other functionality sits in external tools, mainly provided by the platform or GNU. Make has been found insufficient for certain tasks, over time, so that another macro-processor (M4) has been added, mainly for the determination of the capabilites of the host system and external tools. That's the typical Unix model: when you cannot master a job in a shell script, using existing tools, then add another tool. In a new approach I'd provide the interpretation of existing MakeFiles, and extend it to the specific needs and capabilities of the FPC/Lazarus project (package...) model. Then I'd add ports of frequently used tools, as libraries, not only for speed reasons, but also for debugging complex build jobs. WRT time consuming jobs, observed e.g. in building FPC itself, I'd integrate cleaning of the output directories, together with means to reduce the number of such directories, as far as possible. I'd also add FPC as an integrated module, with a reusable file cache to prevent excessive directory scans and loading of configs and modules. The compiler module can be used in the Lazarus IDE as well, either as a built-in module or as a shared library, with beforementioned ability to share the module cache with the application. Unfortunately parallel compilation will never become available with FPC, so that other chances for parallel processing should be explored. As long as the build tasks are based on input/output files (disk I/O), a shared file cache looks like the most promising way for speeding up an build process. When fpmake consists of dedicated modules for various tasks, these modules can be used to build other applications, like test suite runners or profile editors. Just my €0.02 DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
In our previous episode, Hans-Peter Diettrich said: functionality belongs in a different tool (although it could be in fpmake), but let's not limit fpmake only to FPC please. Let us (end users) also play with it ;) My view on (traditional) Make: (Note that if I say packages here, I mean a logical set of units (and maybe tests, docs and examples though IMHO that is secondary). Nothing more, nothing less. IOW don't get BPL visions) I agree with your view on the general Unix status. In a new approach I'd provide the interpretation of existing MakeFiles, and extend it to the specific needs and capabilities of the FPC/Lazarus project (package...) model. Personally I don't think the core makefile principles are worth preserving at all: 1. they are mostly generated anyway. The .fpc files are the info, not the makefiles themselves. 2. they totally pass-by certain core FPC principles (like being to able to compile multiple files in one go. In the packages this is worked around using buildunits) 3. For e.g. a multithreaded compiler, the number of files to be handed to the compiler should increase, not decrease (*) (*) there are multiple issues here to fix: - compiler is not mutithreaded. - module system is scheduled for rewrite for about a decade now - packaging (also static, iow DCP) could decrease number of files and speed up compiler. But what about backend tools? WRT time consuming jobs, observed e.g. in building FPC itself, I'd integrate cleaning of the output directories, together with means to reduce the number of such directories, as far as possible. I'd also add FPC as an integrated module, with a reusable file cache to prevent excessive directory scans and loading of configs and modules. This only works when integrated with FPC, as the compiler finds its own files. But that is all far, far away. The point is more that the current transition horse makeshift situation (fpmake) should be adapatable in the future. At least currently its data is fairly abstract (though I'm not entirely happy having to specify fileinfo manually. That should be based on compiler feedback. But this is very difficult in practice since the exact buildprocess is OS dependant) One big step of fpmake is the killing of tools outside the FPC project like make. The compiler module can be used in the Lazarus IDE as well, either as a built-in module or as a shared library, with beforementioned ability to share the module cache with the application. Unfortunately parallel compilation will never become available with FPC, so that other chances for parallel processing should be explored. As long as the build tasks are based on input/output files (disk I/O), a shared file cache looks like the most promising way for speeding up an build process. Such plans are on the decade scale. If you are interested in it, I'd start creating as many internal assemblers and linkers as possible and further the module-rewrite, and the organizing of units into larger concepts (packages or whatever) and reducing the proliferation of files. When fpmake consists of dedicated modules for various tasks, these modules can be used to build other applications, like test suite runners or profile editors. I think the core bit of fpmake/fppkg should be (1) killing off external tools, and the compromises to package metadata that they force upon up. (2) start developing a logical package concept, both from a building and packaging concept. Maybe with a file based representation (.lib/.dcp like) (3) provide some hooks for packages outside the current main build tree to integrate with release engineering. Both 1 and 2 as a start to more involved systems. At future compiler devel implementing some in-compiler package/library concept or unit cache will more easily roll it out. Point 3 is because there is an enormous rift between package in the tree, and outside of it. By cutting down the administration for this, we might get a more workable external package management. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On 31 Mar 2011, at 13:29, Marco van de Voort wrote: 1. they are mostly generated anyway. The .fpc files are the info, not the makefiles themselves. I still prefer those Makefile.fpc files very much to the fpmake.pp files. The fact that fpmake.pp files are plain Pascal code makes them extremely flexible, but at the same time that also makes it much harder to quickly get an overview of what they do. Sticking to the Makefile.fpc format (or any other structured format) and then automatically generating something else from that (be it plain Makefiles, fpmake.pp or whatever) would make it much easier to maintain the actual build instructions, I think. It would also make it less likely that over time some fpmake.pp will become harder and harder to read. Jonas PS: I assume that currently there already is a way to auto-generate fpmake files like this: http://svn.freepascal.org/svn/fpc/trunk/packages/univint/fpmake.pp (or did you manually derive all those dependencies, or use a quickly hacked together script to parse the uses-clauses of those particular units?) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Thu, 31 Mar 2011, Jonas Maebe wrote: On 31 Mar 2011, at 13:29, Marco van de Voort wrote: 1. they are mostly generated anyway. The .fpc files are the info, not the makefiles themselves. I still prefer those Makefile.fpc files very much to the fpmake.pp files. The idea is to completely get rid of make. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
In our previous episode, Jonas Maebe said: (I have to be careful here, I'm not the fpmake/fppkg person, that is Joost, these are my opinions only) 1. they are mostly generated anyway. The .fpc files are the info, not the makefiles themselves. I still prefer those Makefile.fpc files very much to the fpmake.pp files. The fact that fpmake.pp files are plain Pascal code makes them extremely flexible, but at the same time that also makes it much harder to quickly get an overview of what they do. Well, I can be quite short about this: me too. However I consider this a transitional problem only. We are still in the raw plumbing and discovery phase. In time, I assume some autogeneration helper functionality will emerge to make it at least (way) more bearable. OTOH the trouble should not be exaggerated. I did the entire packages/ hierarchy in a few hrs spread over 2 days, and that was without any previous fpmake experience at all, and communicating with Joost. New packages are not added that often, and I once fpmake/fppkg gets more mainstream, directory layout and general procedures will be more tuned to it. Sticking to the Makefile.fpc format (or any other structured format) and then automatically generating something else from that (be it plain Makefiles, fpmake.pp or whatever) would make it much easier to maintain the actual build instructions, I think. It would also make it less likely that over time some fpmake.pp will become harder and harder to read. The trouble is that makefile.fpc does not contain all information. It is not a closed system, and has barely enough info to build, and depends on the autobuilding capacity of the compiler. Something that can't be used for packaging and other features. The fpmake is more closed. It in theory knows enough to copy files to an isolated environment and compile, and then missing files will turn up. This means that there are ways to potentially validate many aspects of a packages hierachy before a release. PS: I assume that currently there already is a way to auto-generate fpmake files like this: http://svn.freepascal.org/svn/fpc/trunk/packages/univint/fpmake.pp (or did you manually derive all those dependencies, or use a quickly hacked together script to parse the uses-clauses of those particular units?) IIRC there were two solutions. I first did parts with own based small filter programs that parsed -vt output. Later Joost pointed me to some script that was slightly better. For the rest I had a bunch of templates ready. The raw output was then checked and amended for OS and CPU specific cases. It was very semi automatic, but the simple packages (one OS, or no OS/CPU specific data) went fairly fast, and the bulk of the work was customization of the template. I can't exactly remember if this also handled the include situation. Afaik first the units were done, and later includefiles were added. P.s. and initially there was quite some resistance against the .fpc scheme too :-) It worked out fine, mostly due to Peter's very hard work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On 31 Mar 2011, at 14:26, michael.vancann...@wisa.be wrote: On Thu, 31 Mar 2011, Jonas Maebe wrote: On 31 Mar 2011, at 13:29, Marco van de Voort wrote: 1. they are mostly generated anyway. The .fpc files are the info, not the makefiles themselves. I still prefer those Makefile.fpc files very much to the fpmake.pp files. The idea is to completely get rid of make. I know, but I was not discussing that (although I'm not a big fan of doing so either, but I know that's a done deal). What I said was Sticking to the Makefile.fpc format (or any other structured format) and then automatically generating something else from that (be it plain Makefiles, fpmake.pp or whatever) would make it much easier to maintain the actual build instructions, I think. It is possible to stop supporting make without switching to manually writing and maintaining fpmake.pp programs themselves. I don't think that allowing the full flexibility of an arbitrary Pascal program as build instructions a good idea, because it makes maintenance harder and makes it less easy to get a quick overview of what is built/done. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Thu, 31 Mar 2011, Jonas Maebe wrote: On 31 Mar 2011, at 14:26, michael.vancann...@wisa.be wrote: On Thu, 31 Mar 2011, Jonas Maebe wrote: On 31 Mar 2011, at 13:29, Marco van de Voort wrote: 1. they are mostly generated anyway. The .fpc files are the info, not the makefiles themselves. I still prefer those Makefile.fpc files very much to the fpmake.pp files. The idea is to completely get rid of make. I know, but I was not discussing that (although I'm not a big fan of doing so either, but I know that's a done deal). What I said was Sticking to the Makefile.fpc format (or any other structured format) and then automatically generating something else from that (be it plain Makefiles, fpmake.pp or whatever) would make it much easier to maintain the actual build instructions, I think. The problem is that the Makefile.fpc does not contain enough info and logic for our purposes. It is possible to stop supporting make without switching to manually writing and maintaining fpmake.pp programs themselves. I don't think that allowing the full flexibility of an arbitrary Pascal program as build instructions a good idea, because it makes maintenance harder and makes it less easy to get a quick overview of what is built/done. I think you're too pessimistic :-) If you look at the existing fpmake.pp files in the RTL/packages, you'll see that they are still very simple. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On 31 Mar 2011, at 14:42, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: I still prefer those Makefile.fpc files very much to the fpmake.pp files. The fact that fpmake.pp files are plain Pascal code makes them extremely flexible, but at the same time that also makes it much harder to quickly get an overview of what they do. Well, I can be quite short about this: me too. That's good news :) However I consider this a transitional problem only. We are still in the raw plumbing and discovery phase. In time, I assume some autogeneration helper functionality will emerge to make it at least (way) more bearable. That's all I'm asking for. However, auto-generation will exclude directly modifying fpmake.pp (just like you currently can't safely directly edit the Makefiles). The structured format can of course have provisions for injecting Pascal code into the generated fpmake (just like you can insert plain Makefile code via Makefile.fpc), but then at least the parts that are auto-generated and those that are not are strictly separated and cannot be accidently overwritten during an update. Or, in other words: you don't have to spend time on looking for custom code before updating the build instructions. OTOH the trouble should not be exaggerated. I did the entire packages/ hierarchy in a few hrs spread over 2 days, and that was without any previous fpmake experience at all, and communicating with Joost. There's still a difference between initial conversions and maintenance afterwards. The first time there are no potential older changes you might accidentally overwrite. New packages are not added that often, At least the package I referred to (univint) tends to change significantly over time. The Mac OS X 10.6 SDK split a bunch of headers and removed others compared to previous versions (most C programmers use umbrella headers, so they don't notice that either). As Carbon gets phased out, more and more things will probably change. It's not really feasible to manually go through the current list of dependencies and to update them where necessary. Otoh, replacing them with a newly auto-generated list currently risks removing code that someone else added to manually to fix something. The trouble is that makefile.fpc does not contain all information. It is not a closed system, and has barely enough info to build, and depends on the autobuilding capacity of the compiler. Something that can't be used for packaging and other features. That's why I mentioned or any other structured format. IIRC there were two solutions. I first did parts with own based small filter programs that parsed -vt output. Later Joost pointed me to some script that was slightly better. For the rest I had a bunch of templates ready. The raw output was then checked and amended for OS and CPU specific cases. It was very semi automatic, but the simple packages (one OS, or no OS/CPU specific data) went fairly fast, and the bulk of the work was customization of the template. I can't exactly remember if this also handled the include situation. Afaik first the units were done, and later includefiles were added. Unless it's fully automatic so that the current set of dependencies can just be replaced with a new set of generated ones, that's not really doable for univint, I think. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Implementing TFmtBCDField - ftFmtBCD and SQLite
On Thu, 2011-03-24 at 09:43 +0100, LacaK wrote:
after doing some test with new implementation of TFmtBCDField for
TSQLite3Connection connector I encounter this problem:
When you declare in SQLite some column as NUMERIC or DECIMAL then this
column will have NUMERIC affinity.
CREATE TABLE t (d DECIMAL(30,7));
If you insert in such column any numeric value (quoted or unquoted):
INSERT INTO t VALUES('123456789123456789.123456');
SQLite converts such numeric value to 8-byte floating point
representation (REAL) or 8-byte integer (INTEGER), so:
(lost of precision occurs)
SELECT * FROM t;
returns 123456789123456784
Simply said: So Sqlite doesn't support real BCD values. So we can't
support it either for Sqlite.
More difficult: Sqlite is not a 'normal' sql-database. It has all kind
of strange issues, it's own definitions and options. It is impossible to
support all these gimmicks in sqldb. This holds also in a lesser degree
for the other databse-engines, btw.
Practical: (the only important answer) Show me the problem, a bug, or
some code that doesn't work. I think we don't have a problem. Sqldb is
used to read data from existing tables. Sqlite only has very few
data-types (the 'affinities') but to be gentle to our users we do
support more, only based on the field-type name. So as long as users
can't make tables with numeric fields that support more then 15 numbers,
we don't have to support bcd-fields. So map decimal to BCD (not float,
it will be invalid for values within the supported precision range). If
users want to store numbers with an higher precision, that is simply
impossible in sqlite. If they want to store their numbers in
blob-fields, they can simply define a blob field and do so...
So where's the problem? (I see the problem of Sqlite not supporting
bcd-fields, but the sqldb-problem?)
Joost.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
In our previous episode, Jonas Maebe said:
However I consider this a transitional problem only. We are still in
the raw plumbing and discovery phase. In time, I assume some
autogeneration helper functionality will emerge to make it at least
(way) more bearable.
That's all I'm asking for. However, auto-generation will exclude
directly modifying fpmake.pp (just like you currently can't safely
directly edit the Makefiles).
It remains FPC source :-) The autogenerated part can be in an .inc file, and
included from fpmake.pp
Don't forget to include that .inc in the non-source files section though
(exact details obviously not worked out yet) :-)
OTOH the trouble should not be exaggerated. I did the entire packages/
hierarchy in a few hrs spread over 2 days, and that was without any
previous fpmake experience at all, and communicating with Joost.
There's still a difference between initial conversions and maintenance
afterwards. The first time there are no potential older changes you
might accidentally overwrite.
True. Still I don't think it is any different from updating makefile.fpc
with autogenerated unit data. In both cases it is including a block of text
into the rest of the file. And at least fpcmake has the .inc workaround
possibility.
Provided that you can actually generate the content of course. But in
straight cases (files compiled/accessed don't depend on target) this should
be generatable from the output of the compilation of a buildunit.
And the buildunit can be fed with find . -name *.pp |awk print ... just
like the makefile.fpc can.
New packages are not added that often,
At least the package I referred to (univint) tends to change
significantly over time. The Mac OS X 10.6 SDK split a bunch of
headers and removed others compared to previous versions (most C
programmers use umbrella headers, so they don't notice that either).
Maybe more an apache solution? univint105,univint106 etc, and only install
one? (see bits below before you comment on multiple editing)
Speaking of which, I've been thinking about this, and maybe we should
installed most packages one level deeper (e.g. units/$fpctarget/pkgs),
except for versioned packages like httpd/apache. This way the pkgs patch can
be recursively included, and the versioned ones explicitely, with way less
chance on duplicate files in the searchpath.
As Carbon gets phased out, more and more things will probably change.
It's not really feasible to manually go through the current list of
dependencies and to update them where necessary. Otoh, replacing them
with a newly auto-generated list currently risks removing code that
someone else added to manually to fix something.
There is a law of conservation of trouble (wet van behoud van ellende)
going on here. Splitting packages, means doing fixing multiple times,
supporting multiple versions with one set means complicated packaging and
building. Take your pick, trouble each way
But IMHO this is a problem and a tradeoff of this package. The complications
of this package are not the problem of the build system. With any
generalized systems there are winners and losers.
Still, univint _DOES_ seem to meet the criteria to generate fpmake data from
buildunit compilation output. winunits-jedi is another such case, and
probably more OS header sets.
The trouble is that makefile.fpc does not contain all information. It
is not a closed system, and has barely enough info to build, and depends
on the autobuilding capacity of the compiler. Something that can't be
used for packaging and other features.
That's why I mentioned or any other structured format.
Not generalizable. So only for packages where files used and
dependancies on units are not dependant on target. There you can parse
compiler output of a buildunit. (and that could be considered the structured
format, the uses line can be generated using a simple script)
customization of the template.
I can't exactly remember if this also handled the include situation.
Afaik
first the units were done, and later includefiles were added.
Unless it's fully automatic so that the current set of dependencies
The information that must be fixated is quite complicated. This means a
fully automatic way is very, very complicated.
can just be replaced with a new set of generated ones, that's not
really doable for univint, I think.
As said univint (still) falls into the trivial case.
If it gets more complicated, you need source level scanning. IOW parsing
uses and {$i } directives, but somehow follow all nodes of $ifdef
statements. Afaik the current fcl-passrc doesn't allow this, since it
handles preprocessing like the compiler, only evaluating the TRUE parts.
That program should then also get info on include dirs etc. It would be a
nice exercise in tree building :-)
But I hope you realize that I make this last bit up as I go. I doubt we ever
will earn back such an
Re: [fpc-devel] The future of fpmake
On Wed, 2011-03-30 at 21:19 +0200, Darius Blaszyk wrote: On Mar 30, 2011, at 9:08 PM, Michael Van Canneyt wrote: On Mar 30, 2011, at 5:31 PM, michael.vancann...@wisa.be wrote: - managing debug/release builds (also cross-compiling) What is failing in the current system for this ? I was thinking to be able to do something like : fpmake build debug This will add some debug options to the build process. Also it should be possible to create a custom build profile. And how would you do this ? I don't want to complicate fpmake unnecessarily. Improve the command line paring algorithm. It should check if there is something behind the build command line option. If so then it is a named build profile. In fpmake you could check the TDefaults.Profile property to determine which options to add. I step in too late to avoid some long discussions, but here I go: This feature is already there. When you use fpmake directly: -f, if you use fppkg (what I would recommend): fppkg -c. When I want to do a cross-build I can do: fppkg build -c win32 fppkg build -c i386-linux fppkg build -c 244 (use another compiler-version) fppkg build -c debug (well, not cross, but debug-information...) Use 'fppkg listsettings'. It shows which configuration-file it uses, and where you can store your custom configuration-files. (Or 'profiles', if you like that term) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Thu, 2011-03-31 at 15:41 +0200, Jonas Maebe wrote: On 31 Mar 2011, at 14:42, Marco van de Voort wrote: At least the package I referred to (univint) tends to change significantly over time. The Mac OS X 10.6 SDK split a bunch of headers and removed others compared to previous versions (most C programmers use umbrella headers, so they don't notice that either). As Carbon gets phased out, more and more things will probably change. It's not really feasible to manually go through the current list of dependencies and to update them where necessary. Otoh, replacing them with a newly auto-generated list currently risks removing code that someone else added to manually to fix something. The trouble is that makefile.fpc does not contain all information. It is not a closed system, and has barely enough info to build, and depends on the autobuilding capacity of the compiler. Something that can't be used for packaging and other features. That's why I mentioned or any other structured format. It's not a bad idea to see if we can make a structured (and readable) format to create our fpmake.pp files. I was also thinking about letting fpmake detect from the compiler-output if a dependency is missing, and give a warning if this happens, so it can be added. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
Thisnfeature is already there. When you use fpmake directly: -f, if you use fppkg (what I would recommend): fppkg -c. Thanks, I will have a look how it works. I'll try to document it on the wiki. On the side, fppkg is only for FPC right? So not useful for standalone projects. Darius ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
On Thu, 2011-03-31 at 17:47 +0200, dhkblas...@zeelandnet.nl wrote: Thisnfeature is already there. When you use fpmake directly: -f, if you use fppkg (what I would recommend): fppkg -c. Thanks, I will have a look how it works. I'll try to document it on the wiki. On the side, fppkg is only for FPC right? So not useful for standalone projects. You can use fppkg also to install your own (standalone) application, I don't see why not? In fact, fppkg is only a wrapper. When you run fppkg, it will search for a file called 'fpmake.pp'. If this file is found it is compiled and run. There are some extra's, like downloading packages from a repository and installing them. And rebuild all packages which are dependent on the package being re-compiled. For example: if I make a change in fcl-db, and use fppkg to compile install the new version, it will automatically rebuild install all other packages which are depending on fcl-db. With the lazarus-addin it will even mark the Lazarus-package so that it will be recompiled when you compile your program. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The future of fpmake
In our previous episode, Joost van der Sluis said: That's why I mentioned or any other structured format. It's not a bad idea to see if we can make a structured (and readable) format to create our fpmake.pp files. I think the problem goes deeper than this. Makefile.fpc doesn't list unit dependancies (units and .inc files), and fpmake does. It's this detail that is the bulk of the work (at least IMHO, Jonas?) not the fact that one has to wrap p.targets.addunit() around it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
