'temporary' package

[Carter Schonwald]

Interesting. What's an example lib of yours that does this?

On Monday, May 12, 2014, John Meacham <john at repetae.net> wrote:

> On Sun, May 11, 2014 at 11:10 PM, Roman Cheplyaka <roma at ro-che.info<javascript:;>>
> wrote:
> > In this case I'm speaking as an open source library author, whose library
> > depends on temporary.
> >
> > So no, cabal freeze can't help here.
> >
> > Roman
>
> Have you considered autoconf? I know it is a painful syntax due to the
> macro processing, but it is wicked powerful.
>
> Rather than futz around with version numbers or having to magically
> predict the future, I just have macros like
> HC_CHECK_MODULE(Data.Foo,[baz::Int],[packagea,packageb,packagec]) and
> it will check each package for the module with the id of the right
> type and include the first it finds.
>
> If a package maintainer changes behavior that in their mind wasn't
> version breaking that affects me and decides not to bump a version
> number it doesn't matter one bit, I just add a line in my conf file to
> check for the bug and adapt. For more complicated things, I can check
> things like whether instances are defined, size of types and whatnot,
> all one liners. The best part is no need for version number archeology
> or having to wait on anyone else or risk breaking someone else. Any
> changes monotonically increase the portability without breaking it for
> others.
>
> If a package i need is "broken", and i want to release now, I just
> include a patch to the third party package in my dist, autoconf checks
> if it is needed and applies it before building the dependency, I have
> the situation resolved in fifteen minutes rather than having to wait
> on anyone blocking my release. and it is backwards and forwards
> compatible, since it checks whether the patch is needed it won't apply
> it to older versions and when the issue is fixed upstream then it is
> just no longer applied.
>
> I do have a longer term project dealing with autoconfs shortcomings in
> a general way (mainly its sh/unix dependence and m4 quirkyness),
> autoconf's pretty awful in some ways, but not nearly as bad as the
> attempts to replace it.
>
>    John
>
> --
> John Meacham - http://notanumber.net/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140512/a933be74/attachment.html>