Hello,
What is the standard (if any) way of cross-platform development in C for
both Linux and QNX? Do the majority of you just compile with an environment
variable sent to make? Is there an environment variable that exists in both
shells that can be used as the comparison instead of compiling with a
command line env var? I’m just curious as to what are the normal ways that
most of you do cross-platform development.
TIA,
Jim
%% “Jim Lambert” <jlambert@futurex.com> writes:
jl> What is the standard (if any) way of cross-platform development in
jl> C for both Linux and QNX? Do the majority of you just compile
jl> with an environment variable sent to make? Is there an
jl> environment variable that exists in both shells that can be used
jl> as the comparison instead of compiling with a command line env
jl> var? I’m just curious as to what are the normal ways that most of
jl> you do cross-platform development.
You mean, how do you tell inside a makefile what your host platform is?
That’s simple, since both QNX and Linux use GNU make. Try something
like:
HOST_OS := $(shell uname -s)
then $(HOST_OS) will be “Linux” on a Linux box, and “QNX” on QNX.
Of course, remember if you’re cross-compiling what you really care about
is the target platform, not the host platform (except insofar as you
need to find the right cross-compiler), and obviously there’s no way to
“deduce” that if you can build for more than one. The user will have to
specify which one she wants.
These are my opinions—Nortel Networks takes no responsibility for them.
“Jim Lambert” <jlambert@futurex.com> wrote in message
news:a6lb13$k8s$1@inn.qnx.com…
What is the standard (if any) way of cross-platform development in C for
both Linux and QNX? Do the majority of you just compile with an
environment
variable sent to make? Is there an environment variable that exists in
both
shells that can be used as the comparison instead of compiling with a
command line env var? I’m just curious as to what are the normal ways
that
most of you do cross-platform development.
Here’s how we do it:
for OS-dependent code, we use a series of #defines that are split up into
separate OS-dependent headers. We never use an #ifdef LINUX or
#ifdef QNX, except to decide which OS-dependent header to include.
In the headers, there are defines like HAS_UNIX_H, or HAS_QNX4_IPC.
The distinction here is that we are writing code that looks for certain
features of the OS, not the OS itself. This came in very handy when
we wrote the QNX4 SRR module for Linux, and suddenly our Linux
code HAS_QNX4_IPC. All we had to do was turn on this feature in
the Linux-dependent header, without running through our code looking
for #ifdef QNX. This was also pretty important when porting to QNX6,
where #ifdef QNX was true, even though QNX6 bears only a passing
resemblance to QNX4.
For interprocess communication, we wrote our own library that
encapsulates QNX4, QNX6 and SRR/Linux IPC so that our code is
source-compatible across the three systems. We don’t have to play
fancy games with OS-dependencies at the IPC level any more. (This
library is available on our web site if you’re curious - www.cogent.ca).
For Makefiles, we use $(uname -s), as Mr. Smith suggested. If you
use GNU make on all platforms, you can use uname to determine the
OS, and either do the same kind of thing as we’ve done for the C
headers, or be lazy and just use the OS as the determinant. GNU
make has both “include” and “if” directives.
Cheers,
Andrew
Jim Lambert wrote:
Hello,
What is the standard (if any) way of cross-platform development in C for
both Linux and QNX? Do the majority of you just compile with an environment
variable sent to make? Is there an environment variable that exists in both
shells that can be used as the comparison instead of compiling with a
command line env var? I’m just curious as to what are the normal ways that
most of you do cross-platform development.
Our way is to use a platform independent GUI API like Qt, wxWindows or
wxPython.
For platform independent inter process communication we are using the
message passing API of PVM.
This approach allows to write applications which are compatible at
source code level for QNX4, QNX6, Window XY and LINUX.
Armin