All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 5/5] package/zstd: Add option for cli binary
Date: Tue, 15 Jun 2021 23:15:03 +0200	[thread overview]
Message-ID: <d8b91d45-c58b-b8bd-394c-87fac09e385e@mind.be> (raw)
In-Reply-To: <CADYdroPnDVLtebqbg3CshBxyQmTsNCOJzZ_h4uyt4Y8sH04aeg@mail.gmail.com>



On 14/06/2021 23:47, Norbert Lange wrote:
> Am Mo., 14. Juni 2021 um 22:20 Uhr schrieb Arnout Vandecappelle
> <arnout@mind.be>:
>>
>>
>>
>> On 01/06/2021 11:20, Norbert Lange wrote:
>>> Am Mo., 31. Mai 2021 um 17:02 Uhr schrieb Thomas De Schampheleire
>>> <patrickdepinguin@gmail.com>:
>>>>
[snip]
>>>> In fact, I even wonder if it is needed to provide the PROG_DEFAULT at
>>>> all. If shared libraries are supported, I see no reason why one would
>>>> like a static version of the binary.
>>>
>>> upstream treats DSO and programs separately, the static binary could
>>> have some more flags not available for DSO which seem to be considered
>>> less configurable.
>>
>>  I looked at the source and simply see no way how this is even possible - the
>> command line argument parsing is entirely in the source files in the program
>> directory, and there are no different -D options for zstd-dll...
>>
>>> Some time ago I had to use the static library cause some features
>>> where only available there.
>>
>>  Maybe that was in the past and is no longer the case?
> 
> Its still the case, see lib/README.md and the macro ZSTD_STATIC_LINKING_ONLY,
> probably less than some time ago.

 That's for the static library. The programs always define
ZSTD_STATIC_LINKING_ONLY, even when building zstd-dll. Huh, I wonder how that
even works...


> The statically program build could be using those extra features too.

 They *are* using those extra features, so I'm not sure how the dll thing works
even... Maybe they just use inline functions or something like that.



[snip]
>>  However, wouldn't it be more logical to do
>>
>>        { [ ! -e $(@D)/programs/zstd ] && \
> 
> That would fail and stop the build if zstd exists (which is the case
> for zstd-release and zstd-dll but not for zstd-small,
> zstd-decompress).

 Ah, yes, I knew there was a reason why I prefer if ...; then over ... ||

> ie. the build either creates $(@D)/programs/zstd or
> $(@D)/programs/$(ZSTD_BUILD_PROG_TARGET)
> 
> The code that correctly succeeds
> when $(@D)/programs/zstd exists or a link to $(ZSTD_BUILD_PROG_TARGET)
> can be made is:
> 
> [ ! -e $(@D)/programs/$(ZSTD_BUILD_PROG_TARGET) ] || \
>   ln -f $(@D)/programs/$(ZSTD_BUILD_PROG_TARGET) $(@D)/programs/zstd
> 
> or
> 
> [ -e $(@D)/programs/zstd ] || \
>   ln -f $(@D)/programs/$(ZSTD_BUILD_PROG_TARGET) $(@D)/programs/zstd

 Or

	if [ ! -e $(@D)/programs/zstd ]; then \
		ln -f $(@D)/programs/$(ZSTD_BUILD_PROG_TARGET) $(@D)/programs/zstd; \
	fi


[snip]
>>  So in conclusion, I think there should be just one config option
>> BR2_PACKAGE_ZSTD_PROG_FULL (default y) which builds zstd-dll if !static and
>> zstd-release if static.
> 
> hmm, so then we don't need a config?
> I mean zstd-small only has an advantage if no libzstd is used
> (zstd-dll is smaller). At least as it it now,

 Good point. Your v3 is a lot simpler :-)


 Regards,
 Arnout


> perhaps config options with some macros from lib/README.md would make
> more sense...
> 
>>
>>
>>>
>>> Norbert
>>> (Waiting for some more feedback and possibly upstreaming  part of the
>>> series before rerolling)
>>
>>  Good plan :-)
> 
> Procrastination is a super-power.
> 
> Norbert
> 
>>
>>
>>  Regards,
>>  Arnout
>>

  reply	other threads:[~2021-06-15 21:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25 17:26 [Buildroot] [PATCH v2 1/5] package/zstd: bump to version 1.5.0 Norbert Lange
2021-05-25 17:26 ` [Buildroot] [PATCH v2 2/5] package/zstd: Simplify host-build Norbert Lange
2021-06-14 20:20   ` Arnout Vandecappelle
2021-05-25 17:26 ` [Buildroot] [PATCH v2 3/5] package/zstd: rework build and install Norbert Lange
2021-06-14 19:50   ` Arnout Vandecappelle
2021-06-14 21:04     ` Norbert Lange
2021-06-15 20:31       ` Arnout Vandecappelle
2021-05-25 17:26 ` [Buildroot] [PATCH v2 4/5] package/zstd: Change Build options Norbert Lange
2021-06-14 19:56   ` Arnout Vandecappelle
2021-06-14 21:19     ` Norbert Lange
2021-05-25 17:26 ` [Buildroot] [PATCH v2 5/5] package/zstd: Add option for cli binary Norbert Lange
2021-05-31 15:02   ` Thomas De Schampheleire
2021-06-01  9:20     ` Norbert Lange
2021-06-14 20:20       ` Arnout Vandecappelle
2021-06-14 21:47         ` Norbert Lange
2021-06-15 21:15           ` Arnout Vandecappelle [this message]
2021-06-14 20:20 ` [Buildroot] [PATCH v2 1/5] package/zstd: bump to version 1.5.0 Arnout Vandecappelle

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=d8b91d45-c58b-b8bd-394c-87fac09e385e@mind.be \
    --to=arnout@mind.be \
    --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 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.