On Sun, 2022-01-09 at 10:43 +0100, Fabrice Fontaine wrote:
> 
> Le dim. 9 janv. 2022 à 08:27, Gerhard Sittig <gerhard.sit...@gmx.net> a écrit 
> :
> >
> > Mention preferred versions before "also acceptable" fallbacks
> > perhaps? Checks probably also should reflect preference.
> glibmm-2.4 is preferred over glibmm-2.68 in the README and in
> configure.ac (see below).
> I'll update the README.

Indeed I misread your intention and also the autotools condition.
Now I'm even more confused.

You said that 2.68 is the first stable version. Which makes me
assume that versions before that were kind of "preliminary", an
arbitrary state that happened to exist but was not considered an
official release or a stable API to depend on. Can't tell if that
is the case, just stating what I perceive from information that
has become available so far.

That's when it is surprising to me to prefer the arbitrary
non-stable version although a stable version might be available.
Would have expected the preference for stable first and to only
fallback to the older version then. The project may have faced
similar situations with Qt versions, or HIDAPI approaches, or RPC
implementations, or other dependencies.

The autotools logic could have been simple I guess _when_ the
package name had remained stable. The different names (-2.4 vs
-2.68 suffix) are what complicates the implementation of the
check, because this information needs forwarding to the .pc.in
files IIUC. But let's just get the intention clear before any
implementation follows.

Maybe I'm wrong, as stated I don't know this glibmm stuff, and
don't care much about C++ in general, so I lack first hand
experience in that field. I'll happily let others take lead here
as they speak up. Was just responding to that ping of yours.


> > If the data type change and corresponding source update works for
> > glibmm-2.4 already, then I suggest to separate it from the 2.68
> > upgrade. Simplifies review and test, and thus mainline integration.
> As stated in the commit message, DateTime is available since version
> 2.26. I'll split the patch.

Nit about email reply style: The absence of an empty line between
paragraphs makes your response unnecessarily hard to read. Please
consider adding them (actually: leaving them) as is the
tradition, it's just four bytes. There's other stuff that's
easier lost, like HTML crap, or full quotes. :)


virtually yours
Gerhard Sittig
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.


_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Reply via email to