From: Jacob Keller <jacob.e.keller@intel.com>
To: Julia Lawall <julia.lawall@inria.fr>, Olaf Hering <olaf@aepfle.de>
Cc: <cocci@inria.fr>
Subject: Re: [cocci] the future of bundles in coccinelle.git
Date: Tue, 18 Mar 2025 14:52:42 -0700 [thread overview]
Message-ID: <27f57368-6a2d-4ea4-8a81-b8bee42e2d5d@intel.com> (raw)
In-Reply-To: <2b3232fa-ad32-c17f-8e97-8144c648c19c@inria.fr>
On 3/18/2025 3:19 AM, Julia Lawall wrote:
>
>
> On Tue, 18 Mar 2025, Olaf Hering wrote:
>
>> While looking for the proper way to import pcre2, I realized that the
>> way configure.ac looks for required OCaml libraries is ... weird.
>> There is no way to force the usage of the variants in bundles/, the
>> version provided by ocamlfind is always preferred.
>>
>> I think since a while the required build environment is easy to create
>> with either 'opam install $ALL_BUNDLES', or 'zypper install $packages'.
>>
>> Hence I suggest to remove bundles/ and all code referring to it.
Why not go the other route and optionally use the bundles?
>
> No, we don't want to do that. The idea of bundles is to limit the
> dependencies. We don't want users to have the be highly integrated into
> the OCaml ecosystem. Typical Coccinelle users don't care about OCaml at
> all.
>
> Perhaps it is just a personal preference, but when faced with some
> software that eg asks me to install 20 python libraries, I choose some
> other software. I guess others may have the same reaction to software
> that requires installing opam etc.
>
> julia
It can be tricky if asked to install dozens of libraries which aren't
packaged within the distro I'm using. If they do come with the distro
repositories, then I am quite less concerned.
On the other hand I get a bit concerned if I see a couple dozen bundles
which I have no way to know if they stayed up to date with any recent
regressions or vulnerabilities.
That being said, I have had numerous issues in the past when building
coccinelle from source where things failed to compile because of changes
in the versions I had installed by distro vs what was expected. I am not
certain if these were real conflicts or just artifacts of an incorrect
build setup, but I remember my experience being frustrated quite often
any time I had to rebuild from scratch.
next prev parent reply other threads:[~2025-03-18 21:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 10:13 [cocci] the future of bundles in coccinelle.git Olaf Hering
2025-03-18 10:19 ` Julia Lawall
2025-03-18 10:35 ` Olaf Hering
2025-03-18 21:52 ` Jacob Keller [this message]
2025-03-18 22:03 ` Julia Lawall
2025-03-19 12:48 ` Olaf Hering
2025-03-19 13:07 ` Markus Elfring
2025-03-19 13:20 ` Julia Lawall
2025-03-19 13:11 ` Victor Gambier
2025-03-19 13:18 ` Julia Lawall
2025-03-19 13:31 ` Victor Gambier
2025-03-19 13:33 ` Julia Lawall
2025-03-19 13:47 ` Victor Gambier
2025-03-19 13:21 ` Julia Lawall
2025-03-18 15:18 ` Markus Elfring
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=27f57368-6a2d-4ea4-8a81-b8bee42e2d5d@intel.com \
--to=jacob.e.keller@intel.com \
--cc=cocci@inria.fr \
--cc=julia.lawall@inria.fr \
--cc=olaf@aepfle.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.