Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Oct 1997 19:37:40 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        gurney_j@resnet.uoregon.edu
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: how to detect different kernel code (select or poll)
Message-ID:  <199710061937.MAA19102@usr04.primenet.com>
In-Reply-To: <19971006040114.07437@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 6, 97 04:01:14 am

next in thread | previous in thread | raw e-mail | index | archive | help
> what is the best way to conditionally compile code depending if select
> or poll is in the kernel?

PS:

If you do this, remove the #ifdef's when the code is checked in, or
you will have trouble down the road.  Specifically, the version value
in __FreeBSD__ in gcc and the preprocessor is hard-coded when the
compiler and preprocessor are built, so you will be making it
impossible to build your code on a new system without the new compiler.

Likewise, you will make it impossible to cross-build an old system on
a new system with the new compiler.

I ran into both these problems with the if_de.c file.  Please don't
introduce them in the sound driver as well.

Introducing these type of compiler issues is, to my mind, Just Plain
Wrong.


A half-compromise workaround which will make revision control harder:
can you, perhaps, depend on the definition of a manifest constant in
the header defining "poll" instead?  This still makes it a pain to
keep source revisions straight once it's integrated into the source
distributions, since one does not check out a -current file and try
to compile it in a 2.2-stable kernel (one checks out the 2.2 file
instead).

Version information is *implicit* to the source tree.


Or could you distribute as an M4 file?  Then you could macro preprocess
it into one or the other versions.  This would let you, at integration
time, M4 out the oldest version and check it in under the appropriate
version tag, and then the newest, and chek it in the same way.


This is not as satisfying as having a *real* revision history, but at
least it's better than nothing (I've fought exactly this battle with
my FS stuff; if I had a real revision history, I'd have been able to
provide the pieces incrementally instead as a huge all-or-nothing lump).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710061937.MAA19102>