Forum: GNU Radio Compiler preprocessor defines

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ed Criscuolo (Guest)
on 2008-11-03 21:17
(Received via mailing list)
Is there any preprocessor define (or defines) that can be used
when compiling C++ GnuRadio code to differentiate between
different OSs?  I've looked through config.h but didn't see
anything obvious.  I need to compile two different pieces
of code for OSX vs LINUX.

@(^.^)@  Ed
Eric B. (Guest)
on 2008-11-03 21:54
(Received via mailing list)
On Mon, Nov 03, 2008 at 02:16:10PM -0500, Ed Criscuolo wrote:
> Is there any preprocessor define (or defines) that can be used
> when compiling C++ GnuRadio code to differentiate between
> different OSs?  I've looked through config.h but didn't see
> anything obvious.  I need to compile two different pieces
> of code for OSX vs LINUX.
>

FWIW, the "autoconf way" is to test for features, not OS's.
In any event, if you look through config/*.m4 directory you'll find
all sorts of examples.

See also the autoconf manual.

What are you trying to conditionalize?

Eric
Ed Criscuolo (Guest)
on 2008-11-03 22:47
(Received via mailing list)
Eric B. wrote:
> all sorts of examples.
>
> See also the autoconf manual.
>
> What are you trying to conditionalize?
>

The tun/tap pseudo device is implemented very differently
on OSX vs LINUX, UNIX, et al.

Under LINUX et al, you open a single character device, usually
located at /dev/net/tun.  Then, you use ioctl's to to select
the pseudo network device name (tun0, tun1, tap0, tap1, etc) and
set the type (tun vs tap). There's also an option for requesting
a name with the next available number (ie - tun%d or tap%d).

Under OSX, the tun/tap driver precreates the character devices
/dev/tun0 thru /dev/tun15 and /dev/tap0 thru /dev/tap15.  The
application opens the appropriate character device to create the
associated pseudo network device of the same name and type.


@(^.^)@  Ed
Eric B. (Guest)
on 2008-11-03 23:25
(Received via mailing list)
On Mon, Nov 03, 2008 at 03:46:56PM -0500, Ed Criscuolo wrote:
>> In any event, if you look through config/*.m4 directory you'll find
>> all sorts of examples.
>>
>> See also the autoconf manual.
>>
>> What are you trying to conditionalize?
>>
>
> The tun/tap pseudo device is implemented very differently
> on OSX vs LINUX, UNIX, et al.

OK.

Take a look at how we handle the "Fast USB" technique selection.
See config/usrp_fusb_tech.m4.

It would probably be a good idea to abstract the whole "open the
tap/tun device" operation into a separate function, then swig it up so
that it's accessible from python.

Eric
Greg T. (Guest)
on 2008-11-04 15:05
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
removed_email_address@domain.invalid
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Michael D. (Guest)
on 2008-11-04 15:43
(Received via mailing list)
The general way to do this is to create an m4 file with a 'case' in it
based on the "$host_os", e.g. (as taken and expanded from
grc_gr_audio_osx.m4; the case strings may or not be entirely correct,
and are used as examples):
-------------
passed=yes
[set some other global variables to expected values]
case "$host_os" in
  darwin*)
    [set some variable here for Darwin only]
    ;;
  freebsd*)
    [set some variable here for freebsd only]
    ;;
  linux*)
    [set some variable here for linux only]
    ;;
  *)
    [default, maybe print something?; set some variable?]
    passed=no
    ;;
esac
[perform checks on the variables, to make sure they work together; set
"passed=no" on failure]
if test $passed = yes; then
   AC_MSG_RESULT ([passed; using tap/tun FOO])
else
   AC_MSG_RESULT ([failed; not using tap/tun])
fi
Ed Criscuolo (Guest)
on 2008-11-04 21:40
(Received via mailing list)
Michael D. wrote:
>    ;;
> esac
> OSX implements tap/tun between 10.4 and 10.5 ... in that case, there
> would be different 'darwin8*' and 'darwin9*' cases.  The same might hold
> between Linux kernels 2.4.X and 2.6.X, and I'm sure there's a way to
> create cases for each of those.


I've opened ticket #311 to capture this enhancement request, and
associated suggestions.

@(^.^)@  Ed
This topic is locked and can not be replied to.