Emulating C preprocessor's #if

ruby-talk
1

Hi Joel,

My philosophy has been to create separate source files for each platform,
then create a symbolic link to the correct file(s) during the installation
phase. You can look at sys-proctable for a good example of how I do things
(which I adopted from Dan Urist).

This strategy offers a couple of big advantages:

  1. Avoids tons of ifdef’s. This gets especially nasty as the number of
    platforms you’re going to support grows.
  2. Makes testing easier. If I make a change to the Linux source for
    example, I don’t need to go back and retest to make sure I didn’t
    accidentally break something for Solaris or FreeBSD.
  3. Organization. Because my code is less cluttered and consistent (for that
    platform), it’s easier for me to stay focused on what needs to be done for a
    given platform.

There are some drawbacks. If your code is very similar, you’ll be doing a
lot of copy/paste, and if you make a minor change in one platform, you have
to remember to copy/paste it to the other platforms where the code is
identical (at least, if you want consistent behavior between platforms, and
I’m assuming you do). In the cases where you have a method that you know is
platform independent, put it in a separate module and have each platform
independent file include it. Then, you only need to change that method in
one place.

Also, having more files may be a pain for you. It’s more CVS
checkin/checkout for example.

I can safely say I haven’t regretted separating the source one bit, but then
I’ve had relatively small source files to deal with.

Regards,

Dan

···

-----Original Message-----
From: Joel VanderWerf [mailto:vjoel@PATH.Berkeley.EDU]

My example was too simple :slight_smile:

I’m thinking of a case where platform-dependent code is mixed with
independent code and hard to factor out without making a lot of extra
method calls. Also, if you have more variables than just
platform, you
get combinatorial explosion if you have to write a separate
method for
each possibility. My suggestion is a last resort…

2

Berger, Daniel wrote:

There are some drawbacks. If your code is very similar, you’ll be doing a
lot of copy/paste, and if you make a minor change in one platform, you have

That’s what I was trying to avoid…

But I think I will treat this #if approach as a prototyping strategy,
and eventually (as the code matures) only use it at the level of entire
method definitions (as Yuri suggested), rather than within individual
methods.

3

Rubicon does some things that might be similar to what you want (or maybe
not). Have a look at http://www.rubygarden.org/triple-r/index.html

Chad

···

On Fri, 24 Jan 2003, Berger, Daniel wrote:

-----Original Message-----
From: Joel VanderWerf [mailto:vjoel@PATH.Berkeley.EDU]

My example was too simple :slight_smile:

I’m thinking of a case where platform-dependent code is mixed with
independent code and hard to factor out without making a lot of extra
method calls. Also, if you have more variables than just
platform, you
get combinatorial explosion if you have to write a separate
method for
each possibility. My suggestion is a last resort…

Hi Joel,

My philosophy has been to create separate source files for each platform,
then create a symbolic link to the correct file(s) during the installation
phase. You can look at sys-proctable for a good example of how I do things
(which I adopted from Dan Urist).

This strategy offers a couple of big advantages:

  1. Avoids tons of ifdef’s. This gets especially nasty as the number of
    platforms you’re going to support grows.
  2. Makes testing easier. If I make a change to the Linux source for
    example, I don’t need to go back and retest to make sure I didn’t
    accidentally break something for Solaris or FreeBSD.
  3. Organization. Because my code is less cluttered and consistent (for that
    platform), it’s easier for me to stay focused on what needs to be done for a
    given platform.

There are some drawbacks. If your code is very similar, you’ll be doing a
lot of copy/paste, and if you make a minor change in one platform, you have
to remember to copy/paste it to the other platforms where the code is
identical (at least, if you want consistent behavior between platforms, and
I’m assuming you do). In the cases where you have a method that you know is
platform independent, put it in a separate module and have each platform
independent file include it. Then, you only need to change that method in
one place.

Also, having more files may be a pain for you. It’s more CVS
checkin/checkout for example.

I can safely say I haven’t regretted separating the source one bit, but then
I’ve had relatively small source files to deal with.

Regards,

Dan