[fpc-devel] buildfaq

[Hans-Peter Diettrich]

Henry Vermaak schrieb:

>> What does a build system need more[1], 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.


>> [1] Well, sometimes a "--build" switch would be nice, to replace a "make
>> clean".
> 
> fpc -B will build everything regardless of what has changed.

Thanks :-)


>>> 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.

DoDi