linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Philip A. Prindeville" <philipp_subx@redfish-solutions.com>
To: Pavel Roskin <proski@gnu.org>
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>,
	Jon Loeliger <jdl@bigfootnetworks.com>,
	wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] CRDA and cross-compilation
Date: Mon, 10 Aug 2009 17:41:09 -0700	[thread overview]
Message-ID: <4A80BE25.2000800@redfish-solutions.com> (raw)
In-Reply-To: <1249950344.14653.51.camel@mj>

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

Pavel Roskin wrote:
> On Mon, 2009-08-10 at 16:55 -0700, Philip A. Prindeville wrote:
> 
>> You're right: that comment was much more helpful...  does it apply to the first file or the second or both?
>>
>> And what in particular is a mess?
> 
> Cross compilation is not easy.  That's why there are such
> "metadistros" (for the lack of a better word) as buildroot and
> openembedded.  They have special entries for every package that specify
> how to cross-compile it.  There are patches for many sources, although
> it's better to have such files applied to the upstream sources.  But
> it's inevitable that the build is influenced in some way to
> cross-compile, often by specifying variables on the make command line.

Yes, agreed.  We are a downstream user of buildroot.  Unfortunately, not everything we use finds its way upstream to the buildroot repo... so we make certain changes ourselves.

And it's exactly because getting the fixes upstream *is* useful (why fix it in multiple places when you can fix it once???) that I'm being persistent.

I have no problem using variables to make to influence cross-compilation.  Indeed, my patch uses "make ... CROSS_COMPILE=$(TARGET_CROSS)" to work.


> I believe the developers of buildroot and openembedded would be able to
> deal with CRDA as is.  If they find something that could be improved,
> they can send a patch, but I don't think they will bother to change so
> many things as your patch does.
> 
> Besides, it's one thing to follow sane rules that simplify
> cross-compilation, such as providing the fourth argument to
> AC_RUN_IFELSE in configure.ac or not using uname to determine the target
> architecture.  It's another thing to support cross-compilation in a way
> unique to the package.  The gain is miniscule, and the potential for
> breaking is substantial.

There are environments where using pkg-config is every bit as evil using uname.  You just haven't had the unfortunate experience of encountering any yet.

If you're volunteering to add autoconf support to crda, then I accept.  :-)

> Most importantly, you are wasting time of people who could be doing
> something they are better at, such as development of wireless drivers.

By getting wireless drivers to run in yet another environment, I'm augmenting the base of people who will test the code you write.  What I'm doing here isn't without value as well, and some collaboration might be justified.

> There is no point in pushing the same patch over and over again, just
> because you wrote it.  Please try to accept the fact that it's not
> useful for others.  Maybe it was useful for you as an exercise.  But now
> you are not helping.  Please move on and do something else.

You're contradicting yourself.  Above you agree that "specifying variables on the make command line" is a common and acceptable way to indicate cross-compilation.

That's exactly what I'm adding here.



[-- Attachment #2: crda-cross-compile.patch --]
[-- Type: text/plain, Size: 1543 bytes --]

Changes:

1. Move invariant definitions to before any cross-compilation conditional sections for clarity (and to avoid having to duplicate them).

2. Bracket any host (native) compilation sections with conditional based on $(CROSS_COMPILE) being empty.

4. Add 'else' section for cross-compilation using openssl and libnl-1 (or libnl-2 if explicitly selected).


--- crda-1.1.0/Makefile	2009-08-10 13:37:36.000000000 -0700
+++ crda-1.1.0/Makefile.new	2009-08-10 17:29:22.000000000 -0700
@@ -22,12 +22,17 @@
 # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
 PUBKEY_DIR?=pubkeys
 
+MKDIR ?= mkdir -p
+INSTALL ?= install
+
 CFLAGS += -Wall -g
 
 all: all_noverify verify
 
 all_noverify: crda intersect regdbdump
 
+ifeq ($(CROSS_COMPILE),)
+
 ifeq ($(USE_OPENSSL),1)
 CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
 LDLIBS += `pkg-config --libs openssl`
@@ -41,8 +46,6 @@
 reglib.o: keys-gcrypt.c
 
 endif
-MKDIR ?= mkdir -p
-INSTALL ?= install
 
 NL1FOUND := $(shell pkg-config --atleast-version=1 libnl-1 && echo Y)
 NL2FOUND := $(shell pkg-config --atleast-version=2 libnl-2.0 && echo Y)
@@ -64,6 +67,31 @@
 NLLIBS += `pkg-config --libs $(NLLIBNAME)`
 CFLAGS += `pkg-config --cflags $(NLLIBNAME)`
 
+else
+
+ifeq ($(USE_OPENSSL),1)
+CFLAGS += -DUSE_OPENSSL
+LDLIBS += -lssl
+
+reglib.o: keys-ssl.c
+
+else
+CFLAGS += -DUSE_GCRYPT
+LDLIBS += -lgcrypt
+
+reglib.o: keys-gcrypt.c
+
+endif
+
+ifeq ($(USE_LIBNL20),1)
+CFLAGS += -DCONFIG_LIBNL20
+NLLIBS = -lnl-genl -lnl-2.0
+else
+NLLIBS = -lnl
+endif
+
+endif
+
 ifeq ($(V),1)
 Q=
 NQ=@true

  reply	other threads:[~2009-08-11  0:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06  8:08 CRDA and cross-compilation Philip A. Prindeville
2009-08-06 14:46 ` Jon Loeliger
2009-08-06 16:41   ` Pavel Roskin
2009-08-06 16:56     ` Luis R. Rodriguez
2009-08-06 17:38       ` Philip A. Prindeville
2009-08-06 17:45       ` Pavel Roskin
2009-08-06 18:30         ` Philip A. Prindeville
2009-08-06 18:41           ` Pavel Roskin
2009-08-06 18:42         ` Luis R. Rodriguez
2009-08-06 19:08           ` Pavel Roskin
2009-08-06 19:23             ` Luis R. Rodriguez
     [not found]           ` <4A7BD15E.1030604@redfish-solutions.com>
     [not found]             ` <43e72e890908070905s447a2fc0j2dc086048194db34@mail.gmail.com>
     [not found]               ` <4A7CC24D.1000104@redfish-solutions.com>
     [not found]                 ` <1249698462.25983.7.camel@mj>
2009-08-10 22:13                   ` [PATCH] " Philip A. Prindeville
2009-08-10 22:30                     ` Luis R. Rodriguez
2009-08-10 23:55                       ` Philip A. Prindeville
2009-08-11  0:25                         ` Pavel Roskin
2009-08-11  0:41                           ` Philip A. Prindeville [this message]
2009-08-11  5:52                           ` Philip A. Prindeville
2009-08-11  0:41                     ` Philip Craig
2009-08-11  0:45                       ` Philip A. Prindeville
2009-08-06 19:14         ` Philip A. Prindeville
2009-08-06 19:21           ` Jon Loeliger
2009-08-06 15:09 ` John W. Linville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A80BE25.2000800@redfish-solutions.com \
    --to=philipp_subx@redfish-solutions.com \
    --cc=jdl@bigfootnetworks.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@gmail.com \
    --cc=proski@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).