I've some problems with building and testing an new compiler.

1) The buildfaq mentions both PP= and FPC= for the compiler, to be used by Make. It should be made clear whether these are equivalent, or (better) only one option should be used across the entire FAQ.

2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler?

3) Is it possible to give the new compiler an specific name, during Make, so that the original compiler is not inadvertently overwritten by a buggy version?

4) How does FPC handle different targets? IMO every target is implemented in a specific executable, so how does pp or fpc proceed when it is invoked with an target specifier, that it cannot handle itself?

5) A matter of convenience: Currently the easiest way to get both FPC and Lazarus up (on a Windows system) is the installation of Lazarus 0.9.28, including FPC 2.2.4 and all required build tools. That's the latest Lazarus/FPC distribution, available for almost all platforms, that runs off the shelf. Unfortunately the 2.2.4 compiler can not compile the 2.5 sources, so that another binary must be installed. In the worst case multiple (make and install) steps are required, until the 2.5 sources can be compiled by a 2.4 version - including all the RTL stuff. Can we get some more version compatibility?

Thanks
DoDi

Hans-Peter Diettrich wrote

4) How does FPC handle different targets? IMO every target is implemented in a specific executable, so how does pp or fpc proceed when it is invoked with an target specifier, that it cannot handle itself?

fpc is only a wrapper, it tries to find the right compiler.

Just install lastest release lazarus and lastest release fpc: to debug the compiler etc. you can use a compiler compiled with 2.2.4. To test full builds, just use the 2.4.0 compiler. With some shell or batch scripts adapted to your needs, this is quite easy.

From Makefile (line 104):

ifndef FPC
ifdef PP
FPC=$(PP)
endif
endif

2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler?

See Makefile from line 109 onwards. It first looks for fpc(.exe) on the path. If it finds that, it gets the real compiler exe with -PB. If fpc(.exe) isn't found, it tries to find ppc386(.exe) on the path.

On Windows, I usually install latest fpc release, then I check out lazarus and build it. That's pretty simple, no?

Henry

In our previous episode, Hans-Peter Diettrich said:

I've never noticed a difference. This because fpc and ppc<x> mostly support the same switches, and when crosscompiling you generally pass the exact compiler you want anyway.

2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler?

Works for me. It searches in the PATH. It might not look in the current dir though, is that what you mean? That is a make gotcha though.

3) Is it possible to give the new compiler an specific name, during Make, so that the original compiler is not inadvertently overwritten by a buggy version?

IIRC EXENAME=pp_party

4) How does FPC handle different targets? IMO every target is implemented in a specific executable, so how does pp or fpc proceed when it is invoked with an target specifier, that it cannot handle itself?

This is clearly explained in the FAQ. A binary per architecture is the minimal needed configuration.

The maximal possible configuration is an m x m matrix (with m the number of targets), each with a different host-target, dest-target.

I don't see any possibilities here. 2.2.4 + 2.4.0 bridges a major version cycle, and this would mean it would take 2,3 years before any new feature or fix can be used in the fpc repository codebase.

Specially if the only reason is to avoid a small download. The current situation is already enough work.

And of course we couldn't predict that Lazarus would not release anything for 2.4.0

It looks like you will also have to set PPNEW if you do this.

Henry

Thanks, this was the missing link ;-)

2.2.4 cannot compile the 2.5 sources :-(

To test full builds, just use the 2.4.0 compiler. With some shell or batch scripts adapted to your needs, this is quite easy.

Finally I could use 2.4 to build and install 2.5 x86_64-win64 :-)

But fpc now complains that it cannot run ppc386.exe - why? It should be ppcx64, of course, so why does fpc choose the wrong compiler?

DoDi

Hans-Peter Diettrich wrote

But fpc now complains that it cannot run ppc386.exe - why? It should be ppcx64, of course, so why does fpc choose the wrong compiler?

It means that the fpc.exe that you are executing is an i386 binary. By default, it looks for a ppc binary for the same target architecture as the architecture of fpc.exe.

Jonas

I'm not very familiar with the make syntax :-(

Why ppc386, on a 64 bit platform?

Should I copy or add a link, from ppc386.exe to ppcx64.exe?

Installing the latest fpc release is anything but simple :-(

The (currently) last problem is the new fpc.exe, which assumes a 32 bit target, and tries to invoke the (non existing) ppc386.exe. The old 2.2.4 fpc.exe, that came with Lazarus 0.9.28, seems to work properly. But I don't want to test more, instead I simply copied the new ppcx64.exe to ppc386.exe :-)

DoDi

So it's not recommended to use an unqualified name.

This is not what I asked for :-(

Possibly fpc is not rebuilt during make all or make install, when it had already been built for a different target before. Then it assumes the old target, for which it was built before. Possibly...

The maximal possible configuration is an m x m matrix (with m the number of targets), each with a different host-target, dest-target.

You mean when cross-compilers are cross-built? I'm happy with a single compiler for my current machine, it takes enough time to build on Windows :-(

The "small download" of the 2.4 64 bit cross-compiler cannot be avoided, and it requires another cross-build on the 64 bit host=target system. It would be nice to have an combined 32/64 bit release for Windows, not only an cross-compiler. This would be a small effort...

And of course we couldn't predict that Lazarus would not release anything for 2.4.0

AFAIK the Lazarus people are still waiting for a "final" 2.4 release. Only Lazarus 0.9.29 requires at least FPC 2.4, before an FPC 2.2.4 was sufficient.

DoDi

Heh, prepare to lose your mind.

Why ppc386, on a 64 bit platform?

Don't know. It should look for something like ppc$(arch)$(exeext), I guess.

Should I copy or add a link, from ppc386.exe to ppcx64.exe?

Why not just pass FPC when you build?

Hans-Peter Diettrich wrote

I'm not very familiar with the make syntax :-(

There is a book by O'Reily on "GNU MAKE" sitting on my shelf.

I did not yet dare to open it....

-Michael

> I'm not very familiar with the make syntax :-( Heh, prepare to lose your mind.

It's like with the universe - once somebody will figure out, how it works, it will turn immediately into something even more weird.

Some years ago I tried to install autobloat C packages work on Windows. After some tries I knew which foolish tests to erase, and that a Linux/C coder has to learn at least 4 more languages, apart from his programming language. Since that time I know what made C coders what they are ;-)

DoDi

> I'm not very familiar with the make syntax :-( There is a book by O'Reily on "GNU MAKE" sitting on my shelf. I did not yet dare to open it....

It's quite useless, since the C coder community does not accept most of the extensions. Instead they insist in using autobloat, worth 4 more books :-(

DoDi

Hans-Peter Diettrich wrote

autobloat,

I never heard of same ?!?!?

-Michael

Michael Schnell wrote

On 08/04/2010 09:23 PM, Hans-Peter Diettrich wrote: > autobloat, I never heard of same ?!?!?

He means autoconf and automake.

It might be best if everyone would use the normal technical terms instead of derogatory inventions, since it obviously does not help communication (and in the worst case it can trigger someone's annoyance limit).

Jonas

On 08/04/2010 09:23 PM, Hans-Peter Diettrich wrote: > autobloat, I never heard of same ?!?!?

automake, autoconf, configure...

These are tools that try and guess how a project should be adopted to various targets. But it's up to the user to create the tests, with the typical result that all these projects work only for the one platform, that the user is comfortable with.

FPC and Lazarus provide target specific units and include files, for the same purpose, so that the user only has to specify an target. The only problem with this superior approach: not all branches and combinations are complete and bugfree. But at least the platform (widgetset...) specific support must be implemented only once, so that a small team can do all the maintenance [Well, bigger teams were better, of course ;-]

When I discussed a similar solution for portable C projects, in a Linux group, the only reaction was: make it work, then come back. And because nobody was willing to make it work, without further assistance of the platform etc. gurus, every C coder still has to do everything himself...

DoDi

Jonas Maebe wrote

He means autoconf and automake.

They do have their own (very short) chapter in the GNU book.

-Michael

Thanks for the explanation !
-Michael

Build systems seem to be a constant itch. See a list here:

http://en.wikipedia.org/wiki/List_of_build_automation_software

Henry

Build systems seem to be a constant itch. See a list here: http://en.wikipedia.org/wiki/List_of_build_automation_software

Shouldn't we add FPC to that list?

IMO the list completely ignores the existence of platform independent development systems, like for Basic, Java, .NET and other interpreted or VM-based languages. It's a selfmade complication, when a compiler-based programming language allows for a platform-independent RTL, and that chance is not taken in writing portable applications. In so far a portable gcc is only half baked, without an equally portable libc (and other libraries) - at least for writing really portable code.

DoDi

No, because fpc is a compiler, but we can add fpcmake and fpmake.

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?

Gcc/libc is probably the most cross platform compiler/rtl, since you won't have a kernel if gcc isn't ported, and you won't have a userspace if libc isn't ported.

Henry

In our previous episode, Henry Vermaak said:

Gcc/libc is probably the most cross platform compiler/rtl, since you won't have a kernel if gcc isn't ported, and you won't have a userspace if libc isn't ported.

There is no "one" libc. Most *nixes have their own. Linux and a few newer *nix-Mach hybrids (like BeOS) use glibc.

None of them are portable to non *nixes to my best knowledge, so they are not really crossplatform.

gcc is a different matter, at least in the open source world it is fairly dominant. But again, mostly on *nix.

or Lazarus, or FP(?). FPC already introduces the principle, to use an single source file for an entire project, and directories dedicated to specific targets. The source file specifies the output type (app/lib), and command line options select the target. What does a build system need more[1], apart from these options?

[1] Well, sometimes a "--build" switch would be nice, to replace a "make clean".

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.

Gcc/libc is probably the most cross platform compiler/rtl, since you won't have a kernel if gcc isn't ported, and you won't have a userspace if libc isn't ported.

Both gcc and libc can be replaced by other tools and libraries, e.g. by something like FPC and its RTL, only for C instead of Pascal. People already used Delphi for building an OS, with some tweaks to the RTL.

DoDi

Auto select source/paths/components for different back-ends depending on architectures and options, deal with auto-generated source files, build installers, run tests, handle parallel builds, handle cross builds, etc. 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".

[1] Well, sometimes a "--build" switch would be nice, to replace a "make clean".

fpc -B will build everything regardless of what has changed.

You have to compile .net code, afaik.

Henry Vermaak :

Gcc/libc is probably the most cross platform compiler/rtl, since you won't have a kernel if gcc isn't ported, and you won't have a userspace if libc isn't ported.

It wouldn't even fit into the 1'024 bytes of RAM and 16'384 bytes of flash.

Still, there are compilers for such targets.

Vinzent.

> 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 :-)

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