Patch to expose reportProgram in Distribution.Simple.Configure

[Duncan Coutts]

On Sat, 2009-06-06 at 10:32 +0100, Dominic Steinitz wrote:

> > I tend to be a bit reluctant to expose more internal functions to Setup
> > scripts. It means there's more stuff we can't change without breaking
> > packages.
> > 
> > In this case I'm not convinced you need it, running your Setup.hs I get
> > duplicate reports for the programs in question because configure already
> > reports them. The extra warnings are fine of course.
> 
> Obviously, I don't want duplicate reports. But I would like finer
> control of messages. I think I have a valid requirement. What do you
> suggest? Cutting and pasting code seems worse than exposing a function.
> Or maybe something else could be beefed up to allow the user (i.e. me)
> finer control of warning messages?

It's not that huge a problem to export reportProgram but I'm trying to
understand if that's the most helpful thing we can do and I'm still
slightly confused about exactly what it is you want to do and why.

> I did think the interface was slightly clunky but it's probably me
> mis-using it. I seemed to have to specify things twice.
> 
> Once here:
> 
> > perHooks =
> >    simpleUserHooks {
> >          hookedPrograms = [
> >               simpleProgram "pdflatex"
> >             , simpleProgram "asn1c"
> >           ]
> >       , postConf = perPostConf
> >    }

This is so that Cabal knows about them and will try to configure them.
It also lets you refer to them in the .cabal file in the build-tools
field, eg:

build-tools: asn1c

or even

build-tools: asn1c >= 1.0

though in the latter case you have to declare how to find the version
number, rather than just using simpleProgram.

If you use the above then configure will fail if the programs are not
found. Of course that's not quite what you want since you want to merely
warn if they're not found.

> And then because I wanted finer control over the warning messages I
> specified things again. I suspect I could get rid of hookedPrograms (and
> possibly simpleUserHooks). But then I need a function to display the
> results and reportProgram almost does the job (it's just not exposed).

You would be able to report stuff for programs that Cabal already knows
about, but not for ones like this. Though actually you don't seem to use
the programs anywhere else in the Setup.hs, so perhaps you don't need to
bother declaring them. Declaring them allows the user to specify
--with-asn1c=/some/non-standard/dir/ans1c but since you're not ever
running the asn1c in the Setup.hs then that feature is not useful to
you.

You could just try and configure them directly and warn if they're not
found. The only thing declaring them in hookedPrograms is giving you is
that the configure step will try and find the programs and will report
them.

If you don't want the repetition then share the definition of the
programs, eg:

pdflatex = simpleProgram "pdflatex"
asn1c    = simpleProgram "asn1c"

perHooks = simpleUserHooks {
             hookedPrograms = [ pdflatex, asn1c ],
             postConf = perPostConf
           }

perPostConf a cfs pd lbi = do
  let progDb = withPrograms lbi
      v      = fromFlag (configVerbosity cfs)
  case lookupProgram pdflatex progDb of
    Nothing -> warn v
      "Full documentation cannot be built without pdflatex"
    _       -> return ()
  case lookupProgram asn1c progDb of
    Nothing -> warn v
      "Full inter-operability testing cannot be performed without asn1c"
    _       -> return () 

I can see why you want to warn when the programs are not present, but
why do you want to report when they are present, given that they're
already reported? I thought at first it might be that you're trying to
always report these special programs even at the normal verbosity level,
but I see that's not the case.

What behaviour are you trying to achieve?

Duncan