Herbert Valerio Riedel | 18 Sep 12:41 2012
Picon

MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption

Hello,

When I noticed the recently released HTTP-4000.2.5[1] package used a
CABAL-flag based approach[2] for what I expected the use of a macro
MIN_VERSION_network(2,4,0) to be more appropriate (see [3]), I wasn't
totally sure whether there was any down-side with the
MIN_VERSION_-approach. So my question is:

   Is it always desirable to prefer the MIN_VERSION_ approach over a
   CABAL-flag approach for supporting multiple API versions of a
   dependent package (if both ways are possible)? And if not, when
   should I prefer which approach?

 [1]: http://hackage.haskell.org/package/HTTP-4000.2.5
 [2]: https://github.com/haskell/HTTP/commit/7a266219284ff33d66fa5e3f67f406c2616feab5
 [3]: https://github.com/haskell/HTTP/pull/30

cheers,
  hvr
--

-- 
Simon Hengel | 18 Sep 12:59 2012
Picon

Re: MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption

On Tue, Sep 18, 2012 at 12:41:50PM +0200, Herbert Valerio Riedel wrote:
>    Is it always desirable to prefer the MIN_VERSION_ approach over a
>    CABAL-flag approach for supporting multiple API versions of a
>    dependent package (if both ways are possible)? And if not, when
>    should I prefer which approach?

I'm not aware of any advantages of Cabal-flags over MIN_VERSION.

If you use MIN_VERSION you can put

    :set -optP-include -optPdist/build/autogen/cabal_macros.h

into a .ghci, and included it in the packages repository.  That way you
can use GHCi when developing on that package, without passing any CPP
flags explicitly**.  For that reason I prefer the MIN_VERSION-approach.

Cheers,
Simon

** An initial `cabal configure && cabal build` is still required, so
that cabal_macros.h is generated.
Henning Thielemann | 18 Sep 13:05 2012
Picon

Re: MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption


On Tue, 18 Sep 2012, Herbert Valerio Riedel wrote:

> Hello,
>
> When I noticed the recently released HTTP-4000.2.5[1] package used a
> CABAL-flag based approach[2] for what I expected the use of a macro
> MIN_VERSION_network(2,4,0) to be more appropriate (see [3]), I wasn't
> totally sure whether there was any down-side with the
> MIN_VERSION_-approach. So my question is:
>
>   Is it always desirable to prefer the MIN_VERSION_ approach over a
>   CABAL-flag approach for supporting multiple API versions of a
>   dependent package (if both ways are possible)? And if not, when
>   should I prefer which approach?

I prefer the Cabal approach since it requires one (hacky) tool less in the 
tool chain. I use different Hs-Source-Dirs depending on a Cabal flag. With 
ghci you can choose the different modules using the -i option.
Ben Millwood | 18 Sep 14:43 2012
Picon

Re: MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption

On Tue, Sep 18, 2012 at 12:05 PM, Henning Thielemann
<lemming <at> henning-thielemann.de> wrote:
> I prefer the Cabal approach since it requires one (hacky) tool less in the
> tool chain. I use different Hs-Source-Dirs depending on a Cabal flag. With
> ghci you can choose the different modules using the -i option.

I have sympathy with this argument in general, but in this particular
case CPP is used anyway, so that's not much of an argument.

Where CPP is unavoidable, I'd always prefer the MIN_VERSION_ macros
for doing this job.
Herbert Valerio Riedel | 18 Sep 18:03 2012
Picon

Re: MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption

Henning Thielemann <lemming <at> henning-thielemann.de> writes:

> I prefer the Cabal approach since it requires one (hacky) tool less in
> the tool chain. I use different Hs-Source-Dirs depending on a Cabal
> flag. With ghci you can choose the different modules using the -i
> option.

I see, but what about CABAL's version constraint solving algorithm: are
there situations, where using the flag-based approach (to switch between
disjunct version-ranges for a given dependency, thus requiring CABAL to
backtrack on flag-settings iirc) leads to an observably different
"solutions" than those which result when offering CABAL a contiguous
version-range (and defer the version-range "discontinuity" to the CPP
level)? Or are the two approaches "semantically" equivalent from the
CABAL version constraint-solving point-of-view?
wren ng thornton | 20 Sep 00:49 2012

Re: MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption

On 9/18/12 6:41 AM, Herbert Valerio Riedel wrote:
> Hello,
>
> When I noticed the recently released HTTP-4000.2.5[1] package used a
> CABAL-flag based approach[2] for what I expected the use of a macro
> MIN_VERSION_network(2,4,0) to be more appropriate (see [3]), I wasn't
> totally sure whether there was any down-side with the
> MIN_VERSION_-approach. So my question is:
>
>     Is it always desirable to prefer the MIN_VERSION_ approach over a
>     CABAL-flag approach for supporting multiple API versions of a
>     dependent package (if both ways are possible)? And if not, when
>     should I prefer which approach?

If CPP is required, then I think it's preferable to use Cabal's 
MIN_VERSION macros; since, (1) Cabal can figure out the exact 
incantations for you, rather than foisting it upon users, and (2) it 
makes things more consistent across the Haskell ecosystem.

However, the MIN_VERSION macros don't always work. In particular, they 
don't play nice with the hsc2hs preprocessor (and possibly other 
preprocessors as well). So in these cases one must resort to other hackery.

--

-- 
Live well,
~wren
wren ng thornton | 20 Sep 00:52 2012

Re: MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption

On 9/19/12 6:49 PM, wren ng thornton wrote:
> On 9/18/12 6:41 AM, Herbert Valerio Riedel wrote:
>> Hello,
>>
>> When I noticed the recently released HTTP-4000.2.5[1] package used a
>> CABAL-flag based approach[2] for what I expected the use of a macro
>> MIN_VERSION_network(2,4,0) to be more appropriate (see [3]), I wasn't
>> totally sure whether there was any down-side with the
>> MIN_VERSION_-approach. So my question is:
>>
>>     Is it always desirable to prefer the MIN_VERSION_ approach over a
>>     CABAL-flag approach for supporting multiple API versions of a
>>     dependent package (if both ways are possible)? And if not, when
>>     should I prefer which approach?
>
> If CPP is required, then I think it's preferable to use Cabal's
> MIN_VERSION macros; since, (1) Cabal can figure out the exact
> incantations for you, rather than foisting it upon users, and (2) it
> makes things more consistent across the Haskell ecosystem.
>
> However, the MIN_VERSION macros don't always work. In particular, they
> don't play nice with the hsc2hs preprocessor (and possibly other
> preprocessors as well). So in these cases one must resort to other hackery.

Oh, also, it's standard practice to use flags for dealing with the 
vagaries of what's in Base at any given moment. Though this is more for 
enabling Cabal conditionals, rather than for CPP stuff.

--

-- 
Live well,
(Continue reading)


Gmane