A r t i c l e s
Navigation

Note: This site is
a bit older, personal views
may have changed.

M a i n P a g e

D i r e c t o r y

DLL hell or PPU hell


Each time I want to compile some project, I'm always entering search paths for PPU files in my fpc.cfg files or my IDE unit search paths. And the PPU files or paths always end up giving me hell.. so eventually I just start using the -B option to build all units.. then I find myself verifying that I really do have just one fpc compiler installed and not two on my disk, in case the PPU files are conflicting or in case SET PATH is causing problems (some old FPC directory in the environment path).

Then I find out that the -B option is buggy and that it doesn't always rebuild. Usually when I find a bug with the FPC compiler I assume it is me that is the problem, not FPC.. because I'm dumber than FPC. But in some cases it is actually a bug with FPC, and when I find one I deny it.. finally I do rigorous testing (which takes effort) and verify there really is a bug with FPC that I've been living with for the past three years!

(I found what caused -B not to build certain files recently.. it was to do with include files. I spent about three days trying to figure out why my hello-world Powtils program wouldn't compile right.. and of course it was due to a -B build all bug in the FPC compiler.)

Acknowledging or Ignoring

Some pascal programmers don't really acknowledge PPU hell.. they just sort of get used to it and use tools like DELP or they delete all .PPU/.O/.A files manually in a million directories (and sometimes forget directories, and spend 2 days debugging a problem that was due to a PPU mismatch). And some developers use MAKE CLEAN. As long as the makefile is setup to really clean everything! Oh but we were told that FPC developers don't have to use make files.. because FPC isn't Cee and it isn't C++.. yet any semi-serious FPC project ends up using make files... because the fpc compiler isn't smart enough to clean/rebuild things right.

So who is it that complains about DLL hell? And that BPL's won't work because of versioning hell? Methinks we kind of have similar/worse problems with PPU's already anyway.

Developers get used to these bugs and PPU hell with the compiler over time.. and sort of ignore the fact that what they are experiencing with their PPU hell is sometimes worse than DLL hell itself.

Why is it worse than DLL hell at times? It's worse because when I go to download a copy of MSEIDE sources or Lazarus sources.. and I want to customize the IDE.. I have to rebuild the source.. and I end up in PPU hell.. the same hell I would have been if I was using C++ and DLL's.

End users

The advantage of PPU hell over DLL hell is that the end user shouldn't experience PPU hell as much. However with IDE's, the end user is actually the developer himself. You can bet that many Borland Delphi customers will not use FPC simply because they don't wish to spend their life and their entire day piddling around recompiling custom copies of Lazarus/MseIDE and custom copies of patched RTL/FCL to get the IDE working correctly. They'd rather be doing productive things.

Cross Compiling Easy!

Nope. You can also bet that the whole idea of 'cross compiling' is doomed.. especially trying to compile a linux app on a windows machine. People don't have time for the PPU hell that that involves nor the time for the MISSING SYMBOL BLAH BLAH hell that it involves. Many times Win32 PPU's will get accidently mixed up with Unix PPU's when trying to cross compile unless you carefully use the -FUoutputpath option with $FPCTARGET macro. And then you've got to go to some real unix system and find all the unix system files and copy them onto a windows computer.. and yeah, by the time you've done this.. its time to go to bed, and then morning comes.. and you're pretty much screwed.

The only people who will actually put up with this are the ones who are naive and idiotic, like myself.. other people will stick to using one platform.. win32, or linux.. and forget about trying to do cross platform development with a compiler.

And that, my friends, is why more people are using scripting languages and doing web programming these days.. because it's easier just to upload a PHP file to the server and see it work immediately.

Favorite word: proposal

See What is a Proposal

So as a Powtils core developer.. what can I do? Complain, complain? Or offer some proposal? To me, even a 'proposal' is just a discussion (a plan of action). And all plans of action have to have arguing, discussing, moaning, comparing, deciding, etc. Without first discussing and conversing about an issue, you cannot have any final plan! A proposal is all about the moaning and complaining. This is the very reason why people have journals, blogs, meetings, discussions, chats.. the proposal is all about ranting. Smart people complain.. because smart people are always looking for better ways of doing things.. the very act of testing software for bugs is simply a form of complaining and saying 'this software sucks, let's fix it'.

I have solved some of the PPU hell issues by shipping include files in the same directories as PAS files since there is a -B bug in FPC compilers to do with include files. Of course the -B bugs can be sorted out and I've reported the bug and working on a fix, but that doesn't solve the problem of right now.. right now people have older compilers installed on their computers and don't have the latest SVN copy of FPC.. so even if the -B bug is fixed in 2.4/2.3 release, that still means we must work around the issue for people who have older compilers installed (actually when I say older compilers I mean recent compilres.. since almost no one out there sits around compiling the latest SVN unless they have no life, which in some cases is me).

Speaking up about the problems, finding and reporting more bugs instead of ignoring them, coding solutions that fix the problem, etc are all constructive and productive things a developer can do.

That's a feature, not a bug?

One of the problems with developers and humans in general is that they get used to bugs and consider them features. For example one of the MSEIDE bugs where a seg fault occurred people thought was 'as designed'... which is ridiculous.. and even myself for a minute thought 'maybe it was really designed this way so that you could debug your app easier.. if a seg fault occurred at least you knew there was a bug'. This is absolutely ludicrous.. but this is what developers think. So they don't end up reporting the bug, they just consider it a feature and move on.

Pessimistic?

I still have that pessimistic little devil inside of me saying "you're doomed, Ruby and PHP have already won all the developers over and you've got no chance with this compiled stuff.. compilers are so 80-ish technology! No one wants to spend their day compiling crap!". But then again, scripting systems have their versioning problems too such as trying to run PHP3 programs on a PHP5 server with php.ini files that you can't control, and all sorts of other crap.

About
This site is about programming and other things.
_ _ _