[Olsr-dev] NL80211 link quality patch and GIT repository

[Hans-Christoph Steiner]

If you do end up adding libnl support, I would recommend using as
specific macros as possible.  It sounds like __linux__ is much too
general.  GNU/Linux and Android both define __linux__, for example, and
it really means "depends on the Linux kernel".  You might consider
__gnu_linux__ if libnl isn't feasible on Android.

So for libnl, ideally there would be a macro for libnl, so people who
don't have the libnl headers but are building on GNU/Linux would not
have issues.

.hc


On 07/09/2012 03:49 PM, Kees-Jan Hermans wrote:
> Well,
> 
> to be precise, I encountered two recent versions of Debian where one
> would have all userland wireless functionality in libnl, and it would
> have API-version #defines (CONFIG_LIBNL20 and CONFIG_LIBNL30), and one
> that had that library completely split up (in libnl, libnl-nf,
> libnl-cli, libnl-route, libnl-genl), and none of those #defines. So I
> thought, I'd approach this in the following manner:
> 
> 1) Our patch currently only works on Linux (so WIN32 and BSD would have
> to have some elegant message saying 'Sorry, you can't use this right
> now' - this is going to be solved in the code by a '#ifdef __linux__',
> but in the makefile I'd need to be able to switch on the fact that we're
> using Linux or not (I think I've seen a few instances of that in the
> Makefiles already), in order to determine whether or not it's going to
> run the script at all.
> 
> 2) Upon discovery of a few Linux NL-quirks by the script, either a
> Makefile inclusion file is produced, or the present Makefile is altered,
> whichever has your preference (the former has the advantage that running
> the script doesn't alter the GIT state of the present Makefile).
> 
> In the absence of a proper 'configure' script, this is the only elegant
> solution I could think of.
> 
> KJ
> 
> On Mon, 2012-07-09 at 15:17 -0400, Hans-Christoph Steiner wrote:
>> Sure, that's possible with make, which headers and functions are you talking about?
>>
>> My guess is that most likely, you'll want to use #ifdef macros.
>>
>> .hc
>>
>> On Jul 9, 2012, at 11:32 AM, Kees-Jan Hermans wrote:
>>
>>> Ok, thanks. Turns out that what I thought was new, was old, and vice
>>> versa. Spent some of the weekend adapting a patch against the old code.
>>> My mistake I suppose - teach me the basics of this here project ;-)
>>>
>>> Anyway, some patching up was necessary anyhow (mostly, unfortunately,
>>> due to the fact that there is no stable nl80211 userland API on Linux,
>>> differing wildly among distributions and no real sure way to know what
>>> version you're dealing with on the basis of #defines and whatnot)
>>>
>>> Which leads me to another question: is there something in the course of
>>> 'make' that I could use to create a 'configure' like situation
>>> (discovery of certain uses of header files, function prototypes and
>>> defines) ?
>>>
>>> Sincerely,
>>>
>>> KJ
>>>
>>> On Mon, 2012-07-09 at 16:49 +0200, Henning Rogge wrote:
>>>> On 07/09/2012 04:45 PM, Kees-Jan Hermans wrote:
>>>>> Dear all,
>>>>>
>>>>> I've been working on renewing the patch for using wireless lan metrics
>>>>> as part of the link quality cost calculation, but I've been a bit
>>>>> confused as to how the repository works; it seems that the default
>>>>> 'master' branch is old, and the 'stable' branch is where everyone is
>>>>> committing their new code against. Is that correct? I'm just asking,
>>>>> because in other places, such nomenclature would suggest a different,
>>>>> and opposite, function.
>>>>
>>>> Yes, thats right.
>>>>
>>>> We were also in the process of discussing a change in the "where to 
>>>> commit and how to do it" policy here when I got hit by an "eat up a 
>>>> whole week of time" thing...
>>>>
>>>> Hope we will restart the discussion soon and sort it out.
>>>>
>>>> Henning
>>>>
>>>>
>>>
>>> -- 
>>> Olsr-dev mailing list
>>> (spam-protected)
>>> https://lists.olsr.org/mailman/listinfo/olsr-dev
>>
>