Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Libcurl : to depend or not to depend ?
Date: Wed, 21 Mar 2012 18:05:45 +0100	[thread overview]
Message-ID: <20120321180545.02ab322f@skate> (raw)
In-Reply-To: <AD9141CB33AC4D019D399FFCCB3E46D3@JohanW7>

Hello,

Le Wed, 21 Mar 2012 17:50:26 +0100,
"Sagaert Johan" <sagaert.johan@skynet.be> a ?crit :

> I know what to do, but in case you need openssl and you also want libcurl BUT without SSL there is no way to build it like it is
> now.

Correct. Presumably, the size impact of OpenSSL support in libcurl is
pretty small (OpenSSL itself is huge, but the OpenSSL support in
libcurl is most likely relatively small), so it is generally not
necessary.

We might of course add a libcurl suboption to make this configurable,
but for most packages, the OpenSSL support is automatically enabled if
OpenSSL is present.

> The trick i use now to build libcurl without ssl is 
> 	disabling openssl
> 	build (libcurl gets build without SSL)
> 	enable openssl
> 	build (libcurl does'nt change and i also have openssl now.)

Or just modify libcurl.mk so that it always passes --without-ssl
regardless of whether OpenSSL is selected or not. I think it's much
easier.

I don't think Buildroot can really adapt to each and every situation
(and still be maintainable), and some special situations require direct
modifications of the .mk file. For example, not later than today, I had
to:

 * Change openssl.mk because I wanted to build only the static version
   (OpenSSL in my case was used only by one application, and linking
   OpenSSL statically against this application allowed some space
   savings)

 * Change avahi.mk to build the Avahi libraries statically, for the
   same reasons (only used by Avahi programs themselves, so it allows
   some space savings)

I just maintain those project-specific tweaks in a Git branch. They are
simple, so when I need to upgrade Buildroot they are not a big issue.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2012-03-21 17:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-21 15:06 [Buildroot] Libcurl : to depend or not to depend ? Sagaert Johan
2012-03-21 15:20 ` Thomas Petazzoni
2012-03-21 16:50   ` Sagaert Johan
2012-03-21 17:05     ` Thomas Petazzoni [this message]
2012-03-21 22:00     ` Peter Korsgaard
2012-03-21 22:30       ` Thomas Petazzoni

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=20120321180545.02ab322f@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /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