Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2009-05

Dependencies of FPC_HAS_FEATURE_XXX

3 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Sven Barth

Hello together!

As you (might) know I'm currently implementing the RTL for NT's native usermode API and I found some (at least in my opinion) unnecessary dependencies in FPC's FPC_HAS_FEATURE_XXX system.

If I disable all features (by simply undef-ing them before the inclusion of systemh.inc) the platform dependent code (in my case i386) asks for the function "fpc_truely_ansistr_unique" which is included only if FPC_HAS_FEATURE_ANSISTRINGS is defined (that's not very nice ^^ ). When I enable the ansistrings the compiler asks for the heap methods. That's natural and so I'm ok with it.
But the heap feature relies on the threading feature, which is really annoying: now I have to implement critical section support, what I wanted to do at a later time (although I could simply stub the procedures).

In my (!) opinion those two cases (i386.inc and heap.inc) should check whether the features, which they "optionally" depend on, are enabled .

So... before I write a bug report about this, I wanted to ask you if this behavior is by design or just a bug that no one encountered, because no one enabled the features step by step? ;)

Greetings,
Sven

PS: Just curios: why does system.pp set mode to objfpc?

Sven Barth

Hello again!

I found the next ones: the threading feature depends on exceptions (InitStdExceptions) and I/O (InitStdIO) (both not easy to implement). Also it uses CheckInitialStkLength. The declaration of this function is enclosed by FPC_HAS_FEATURE_STACKCHECK, so the call should be enclosed, too.

I really consider this dependencies as a bug... but I'll wait for your opinions (at least some days :P ).

Hmm... if this speeds things up: shall I enclose the problematic places with ifdefs and send a patch along with the bug report?

Regards,
Sven

Micha Nelissen
to Sven Barth
Sven Barth wrote
Hmm... if this speeds things up: shall I enclose the problematic places with ifdefs and send a patch along with the bug report?

Got response yet? If not then yes, please send patches per topic to ifdef the optional code away.

Micha