From: Jean Delvare <jdelvare@suse.de>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [PATCH] i2c-tools: enable static use of libi2c
Date: Wed, 17 Jun 2015 15:10:25 +0200 [thread overview]
Message-ID: <20150617151025.1353abe3@endymion.delvare> (raw)
In-Reply-To: <20150617105309.GF1517@katana>
On Wed, 17 Jun 2015 12:53:09 +0200, Wolfram Sang wrote:
> Hi Jean,
>
> > > When debugging embedded systems, it is often nice to simply TFTP the
> > > desired i2ctool to the target without the hazzle of dealing with shared
> > > libs. Using -static is overkill, too, so let's add a switch which will
> > > only link functions from libi2c statically.
> >
> > Fine with me.
>
> Hooray!
>
> > > BUILD_STATIC_LIB ?= 1
> > > +# Uncomment to use static libi2c
> > > +#USE_STATIC_LIB := 1
> >
> > Any reason for not using ?= as above, with the default being unset?
>
> Agreed.
>
> > Unrelated to your patch, but shouldn't this -Llib rather been written
> > -L$(LIB_DIR)?
>
> Yes, makes sense.
OK, I'll fix it after applying your updated patch.
> > Also it might make sense to check if USE_STATIC_LIB is set when
> > BUILD_STATIC_LIB isn't and complain about it?
>
> For easier usage, I'd rather enforce BUILD_STATIC_LIB in that case.
You mean that USE_STATIC_LIB = 1 would silently imply
BUILD_STATIC_LIB = 1? Yes, that's much better than my proposal.
I'm wondering if we should make it even more flexible, but I'm not sure
if it's worth the effort... Are you calling "make install" after that?
I guess not.
--
Jean Delvare
SUSE L3 Support
WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <jdelvare@suse.de>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org, linux-sh@vger.kernel.org
Subject: Re: [PATCH] i2c-tools: enable static use of libi2c
Date: Wed, 17 Jun 2015 13:10:25 +0000 [thread overview]
Message-ID: <20150617151025.1353abe3@endymion.delvare> (raw)
In-Reply-To: <20150617105309.GF1517@katana>
On Wed, 17 Jun 2015 12:53:09 +0200, Wolfram Sang wrote:
> Hi Jean,
>
> > > When debugging embedded systems, it is often nice to simply TFTP the
> > > desired i2ctool to the target without the hazzle of dealing with shared
> > > libs. Using -static is overkill, too, so let's add a switch which will
> > > only link functions from libi2c statically.
> >
> > Fine with me.
>
> Hooray!
>
> > > BUILD_STATIC_LIB ?= 1
> > > +# Uncomment to use static libi2c
> > > +#USE_STATIC_LIB := 1
> >
> > Any reason for not using ?= as above, with the default being unset?
>
> Agreed.
>
> > Unrelated to your patch, but shouldn't this -Llib rather been written
> > -L$(LIB_DIR)?
>
> Yes, makes sense.
OK, I'll fix it after applying your updated patch.
> > Also it might make sense to check if USE_STATIC_LIB is set when
> > BUILD_STATIC_LIB isn't and complain about it?
>
> For easier usage, I'd rather enforce BUILD_STATIC_LIB in that case.
You mean that USE_STATIC_LIB = 1 would silently imply
BUILD_STATIC_LIB = 1? Yes, that's much better than my proposal.
I'm wondering if we should make it even more flexible, but I'm not sure
if it's worth the effort... Are you calling "make install" after that?
I guess not.
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2015-06-17 13:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 2:01 [PATCH] i2c-tools: enable static use of libi2c Wolfram Sang
2015-06-16 2:01 ` Wolfram Sang
[not found] ` <1434420079-3029-1-git-send-email-wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
2015-06-17 9:06 ` Jean Delvare
2015-06-17 9:06 ` Jean Delvare
2015-06-17 10:53 ` Wolfram Sang
2015-06-17 10:53 ` Wolfram Sang
2015-06-17 13:10 ` Jean Delvare [this message]
2015-06-17 13:10 ` Jean Delvare
[not found] ` <20150617151025.1353abe3-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2015-06-17 13:20 ` Wolfram Sang
2015-06-17 13:20 ` Wolfram Sang
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=20150617151025.1353abe3@endymion.delvare \
--to=jdelvare@suse.de \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=wsa@the-dreams.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.