[prev in list] [next in list] [prev in thread] [next in thread]
List: macports-dev
Subject: Re: LIBUSB -legacy only- Poll
From: "Michael Dickens" <michaelld () macports ! org>
Date: 2010-08-31 15:32:33
Message-ID: 1283268753.25323.1392643959 () webmail ! messagingengine ! com
[Download RAW message or body]
This is a multi-part message in MIME format.
--_----------=_1283268753253230
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 31 Aug 2010 11:32:33 -0400
X-Mailer: MessagingEngine.com Webmail Interface
Hi Bradley -
On Aug 31, 2010, at 11:00 AM, Bradley Giesbrecht wrote:
Wouldn't adding your desired flags to the front of
configure.env, configure.pre_args or where ever else needed
work?
I suppose I could change the compiler from "gcc" to "gcc
-L${prefix}/lib/libusb-legacy -L${prefix}/lib", but that seems
like an awkward solution for such a problem. I cannot think of
another environment variable change that would provide the
desired result; there are no configure flags that would be of
help; setting USB_CFLAGS and so forth will not work because of
the ordering the Makefile.in's. GNU Radio uses the GNU Autotools
for the build system, which provides a "buffer" between the
calling environment and the build environment. Whatever the GR
configure script finds for paths are then used by the
Makefile.am's, specifically as they are programmed, without
regard to the ordering in the calling environment. So, even if I
set LDFLAGS (or whatever) to be ordered
"${prefix}/lib/libusb-legacy ${prefix}/lib", that ordering would
be modified in the Makefile.am's as they are programmed, and
hence not necessarily be what I wanted.
For the case of GNU Radio's build system, I would need to modify
the Makefile.in's to change the ordering. And, then,
I/we/MacPorts would need to make similar modifications for any
other project that uses this library (not that there are any of
which I know, but hypothetically there might be). So, a more
robust solution is to rename the library & force the other
projects to rebuild to find that new library. In this case, I
see it as a reasonable solution because:
(1) libusb-legacy is already installed in non-standard locations.
(2) libusb-legacy is not in significant use any longer; all
(soon) ports use the 'compat' library instead.
(3) nobody has submitted tickets with issues due to (1), I would
guess primarily because of (2).
(4) external-to-MacPorts projects should be using the PKGCONFIG
files to determine the CFLAGS, LDFLAGS, and so forth for LIBUSB
(whatever version); I would hope that in this day and age,
hard-wiring paths is no longer the norm.
I hope this (most than) answers your question. - MLD
--_----------=_1283268753253230
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"
Date: Tue, 31 Aug 2010 11:32:33 -0400
X-Mailer: MessagingEngine.com Webmail Interface
<!--/*SC*/DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" \
"http://www.w3.org/TR/html4/loose.dtd"/*EC*/--> <html><head><title></title><style \
type="text/css"><!--body{padding:1ex;margin:0px;font-family:sans-serif;font-size:small;}a[href]{color:-moz-hyperlinktext \
!important;text-decoration:-moz-anchor-decoration;}blockquote{margin:0;border-left:2px \
solid #144fae;padding-left:1em;}blockquote \
blockquote{border-color:#006312;}blockquote blockquote \
blockquote{border-color:#540000;}--></style></head><body><div style="font-family: \
Arial; font-size: medium;" dir="ltr"><div> <div>Hi Bradley -</div>
<div> </div>
</div>
<div>On Aug 31, 2010, at 11:00 AM, Bradley Giesbrecht wrote:</div>
<blockquote type="cite">Wouldn't adding your desired flags to the front of \
configure.env, configure.pre_args or where ever else needed work?</blockquote> \
<div> </div> <div>I suppose I could change the compiler from "gcc" to \
"gcc -L${prefix}/lib/libusb-legacy -L${prefix}/lib", but that seems like an \
awkward solution for such a problem. I cannot think of another environment \
variable change that would provide the desired result; there are no configure flags \
that would be of help; setting USB_CFLAGS and so forth will not work because of the \
ordering the Makefile.in's. GNU Radio uses the GNU Autotools for the build \
system, which provides a "buffer" between the calling environment and the \
build environment. Whatever the GR configure script finds for paths are then \
used by the Makefile.am's, specifically as they are programmed, without regard to the \
ordering in the calling environment. So, even if I set LDFLAGS (or whatever) to \
be ordered "${prefix}/lib/libusb-legacy ${prefix}/lib", that ordering would \
be modified in the Makefile.am's as they are programmed, and hence not necessarily be \
what I wanted.</div> <div> </div>
<div>For the case of GNU Radio's build system, I would need to modify the \
Makefile.in's to change the ordering. And, then, I/we/MacPorts would need to \
make similar modifications for any other project that uses this library (not that \
there are any of which I know, but hypothetically there might be). So, a more \
robust solution is to rename the library & force the other projects to rebuild to \
find that new library. In this case, I see it as a reasonable solution \
because:</div> <div> </div>
<div>(1) libusb-legacy is already installed in non-standard locations.</div>
<div> </div>
<div>(2) libusb-legacy is not in significant use any longer; all (soon) ports \
use the 'compat' library instead.</div> <div> </div>
<div>(3) nobody has submitted tickets with issues due to (1), I would guess primarily \
because of (2).</div> <div> </div>
<div>(4) external-to-MacPorts projects should be using the PKGCONFIG files to \
determine the CFLAGS, LDFLAGS, and so forth for LIBUSB (whatever version); I would \
hope that in this day and age, hard-wiring paths is no longer the norm.</div> \
<div> </div> <div>I hope this (most than) answers your question. - MLD</div>
<div> </div></div></body></html>
--_----------=_1283268753253230--
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic