DrDiettrich1 at aol.com
Sat Aug 7 03:30:38 CEST 2010
Henry Vermaak schrieb:
>> What does a build system need more, apart from these options?
> Auto select source/paths/components for different back-ends depending
> on architectures and options,
as is done by Lazarus/fpc
> deal with auto-generated source files,
> build installers, run tests, handle parallel builds, handle cross
> builds, etc.
Thats a matter of scope and habits. The definition
"Build automation involves scripting or automating the process of
compiling computer source code into binary code."
leaves open what should be automated, using what features. Above
requirements look to me like batch processing, doable with e.g. the
Delphi project groups, or ordinary script/batch files. Or, as I see it,
it can be achieved by a source module that contains the "script" as
ordinary (Pascal) code, that should be run after it has been parsed or
compiled. Eventually required (external) tools are components, usable in
code just like other libraries are.
> Why do you think these build systems exist? Many
> projects have very complex requirements that you can't solve with "a
> single source file for an entire project".
Depends on the definition of "project". When *installable* packages are
meant, then I agree that the construction of such packages (deb,
rpm...), or of a setup program that shall run on the target system, is
out of the scope of an compiler.
>>  Well, sometimes a "--build" switch would be nice, to replace a "make
> fpc -B will build everything regardless of what has changed.
>>> I really don't have a clue what you mean. The list shows build
>>> automation software. A lot of those are platform independent and
>>> language dependant. What does this have to do with Basic/Java/.Net?
>> For these languages no build system is required, because the same code runs
>> on every (supported) platform.
> You have to compile .net code, afaik.
Yes, and that is *exactly* the task of an compiler. The compiler output
(assembly) can be distributed and used as is, no need for any other
"build" actions. If somebody *thinks* that he needs more than that, then
he should explain the *real* need for that "more" to me - otherwise we
only talk about different things. No offense intended, I only want to
understand what you or the rest of the world understands by "build
system", and why such systems are definitely required.
Perhaps it helps to start from the opposite end, i.e. describing the
*result* of the build process, before we discuss the assumed or really
required features, needed to construct that result. When the answer is
something like "Windows requires installer packages that consist of
these [...] parts", then I'd simply say that this is the wrong way to
distribute portable code. Even Windows *allows* to run applications
without any further installation.
I agree that some management of "installed" (locally available)
libraries or applications is desireable, so that dependencies can be
resolved automatically, or unused components can be removed easily. When
this is in the scope of a "build" system, then I see no further need for
a discussion of the details of such *existing* management systems, and
how complicated it is to obtain the required distribution kits -
everything *is* as it is. With regards to building (portable) software I
see more sense in a discussion of an according (portable) distribution
and installation system, that makes specialized build tools superfluous.
But such a discussion, of msi/deb/rpm/jar... systems, is OT here and
should be continued somewhere else.
More information about the fpc-devel