Hello, we have a special use case where we want to use the new network stack but without the IPv6 support. I could need some advice how this could be integrated into the waf build system. If we find a good solution, this could also be an example for other BSD Kernel options.
I found multiple places where IPv6 is enabled in libbsd: If I remove the INET6 option out of the FreeBSD kernel configuration on a FreeBSD system, this has the effect, that the "opt_inet6.h" is generated as an empty file instead of with a single define "#define INET6 1". In the rtems-libbsd the configuration header is located at rtemsbsd/include/rtems/bsd/local/opt_inet6.h. It has a fixed content with the define set. This would be the first place where the support would have to be disabled. Beneath that, some user space tools have a special option to enable IPv6 which is currently set in libbsd.py. One such example is tcpdump with a compiler flag '-DINET6' set. As far as I could tell, the kernel and every application that is included in libbsd currently uses the INET6 macro. But I think this is more of a convention than a general rule. So I think we would roughly need the following: If i configure libbsd using waf configure --disable-ipv6 the build system would either have to regenerate opt_inet6.h or use an alternative version of it. Further I would need the ability to set compiler flags in libbsd.py depending on this configure option. Are there any better ideas how to implement such an option? I'm quite inexperienced on how to use waf, so I would need some guidance how this could be implemented. Are there any hints how I could start implementing such an option? Some examples or similar code? Kind regards Christian Mauderer -- -------------------------------------------- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
