'temporary' package

Mon May 12 19:28:03 UTC 2014

The main public one that does interesting things would be jhc, here is
its autoconf http://repetae.net/repos/jhc/configure.ac . Some
interesting things it does is look for both readline and editline and
decide which one or neither to use, it will compile no matter what is
installed however. it checks whether  haskell98 and base are
compatible, and if not, adds a compatibility layer, and checks for an
instance of Monoid Doc, generating one if needed but not including it
otherwise to avoid duplicate instances.

Until recently this gave me compatibility back to ghc 6.8 for a pretty
complex package. (I bumped the minimum to 7.2 conciously because I
decided view patterns and field punning were just way to useful to not
use, it allowed me to drop some other autoconf rules). But i never
needed to dig into exactly which version numbers of stuff made the
changes i care about, and my tests will work for any compiler, not
just ghc. I was never blocked for long by a change in an external
package. in fact, there very well could not be a global version number
combo that lets me compile without the targeted checks, a lot of the
code is shared between other projects and needs broader ranges of
ghc/jhc compatibility.

Now some more interesting stuff is going on here
http://repetae.net/repos/jhc/lib/ext/ it has patches to fix up
versions of libraries, my build script will pull the version from
hackage with wget then apply the patch and build. Ignore the fact that
some have .cabal extensions, historical quirk I am excising, It was
way more confusing to have cabal files with jhc when none of the
public cabal files actually work with it. now jhc uses fully
declarative yaml files,

 Ironically, people ask when jhc will support cabal when it does, it
has for a while, it just doesn't help at all due to cabals design,
looking at even the simplest cabal project
(https://hackage.haskell.org/package/bytestring) has its dependencies
in terms of ghc-prim and specific versions of base, (including,
perplexingly, a maximum version, precognitive abilities are apparently
a requirement for using hackage; that should have been a sign
something was off in the design.). But the important thing is, under
cabals rules it would and does just give up with jhc despite it
compiling just fine under it, as it has a different base and no
ghc-prim. And I can't even try to reverse engineer the file because
base > 4.2 gives no indication of _why_ that version is needed, every
hackage package is like this, refering to specific versions that only
make sense in the context of ghc and have no actual information about
what is needed from the environment. I suppose i could bug each and
every hackage author to stick 'if jhc' sections and get pissy on the
lists when they don't keep them up to date, and, like guessing future
version maximums most would just have to guess about what jhc needs.
In any case, a system that grows as the square of the number of
compilers and packages clearly won't work in the long run. hackage is
depressingly antagonistic to other compilers and grossly ghc specific
as an ecosystem, not just ghc specific, but ghc-haskell over the last
couple versions specific due to having to get on the cabal dependency
maintenence treadmill when your guessed maximum versions are reached,
then, under cabals design, have to go back and add new sections when
people want to use different compilers.

An idea i have been playing with to replace autoconf with something
feature compatible is adding a portable '/bin/sh' and windows
powershell (is there a better universal windows scripting format?)
backend to jhc, one of the main issues with autoconf is there is no
insulation between the backend (portable  sh) and the front end, m4
macros that generate portable sh. Adding a new target like windows is
hard. By insulating the configuration language with an actual compiler
it would plug that major hole. Plus, it is the perfect poster child
for where strong typing is needed, you are writing code for systems
that you specifically don't have access too to test on as a goal.
Because these scripts are supposed to work for systems that will be
invented in the future or your neighbors machine running ObscureBSD,
so catching bugs at compile time is a huge boon for branches you will
likely never be able to test yourself.

     John

On Mon, May 12, 2014 at 8:13 AM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> 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>
>> 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
>> http://www.haskell.org/mailman/listinfo/libraries

-- 
John Meacham - http://notanumber.net/