Re: [dev] [OFFTOPIC] Recommended meta-build system

On Tue, Feb 2, 2010 at 12:23 AM, pancake <pancake_AT_youterm.com> wrote:
> On Mon, 1 Feb 2010 22:31:38 +0100
> Uriel <lost.goblin_AT_gmail.com> wrote:
>
>> On Mon, Feb 1, 2010 at 2:20 PM, pancake <pancake_AT_youterm.com> wrote:
>> > anonymous wrote:
>> >>>
>> >>> Having said that, in case of rfork vice versa from FreeBSD.
>> >>>
>> >>
>> >> Yes, I am talking about FreeBSD. With configure you can make your
>> >> program portable between FreeBSD and Linux. Most probably other
>> >> systems won't implement clone/rfork their own way so program will be
>> >> portable between all systems with some kind of rfork implementation.
>> >>
>> >
>> > in that specific case i would prefer to use __FreeBSD__ ifdef instead of a
>> > configure stage.
>>
>> This is totally and completely RETARDED. #ifdefs are a disgrace and
>> people that use them should be shot on sight.
>
> if you deny ifdefs for minimal portability fixes and deny configure options
> to specify OS or way to compile this program you are denying also portability
> and incrementing the complexity in development and structuration.

This claim is patently ridiculous and wrong. As The Practice of
Programming points out the only proper way to write portable code is
to restrict yourself to the shared subset of interfaces available on
all desired platforms, this certainly *reduces* complexity, and there
are tons of software out there that use this approach and work just
fine on pretty much any platform imaginable.

Hell even dwm has no ifdefs or configuration step (or it didn't until
stupid XINERAMA support was added).

If due to the nature of the app one *really* needs to access
system-specific APIs (this is much more rare than people claims to the
point that I had trouble finding an example)) there are perfectly fine
ways to do this without using a retarded configuration step or insane
#ifdefs, for an example of how to do this see drawterm:
http://code.swtch.com/drawterm/src/ (and yes, drawterm has a handful
of ifdefs but most of them are either to comment out code or to enable
some compiler specific pragmas, and the rest should be done away with
and as far as I can tell were added by people that didn't quite know
how to do things properly).

uriel
Received on Tue Feb 02 2010 - 07:54:10 UTC