Patch to expose reportProgram in Distribution.Simple.Configure
I found this useful - see http://code.haskell.org/asn1/Setup.hs for an example. Dominic.
Dominic Steinitz wrote:
I found this useful - see http://code.haskell.org/asn1/Setup.hs for an example.
Dominic.
Any news on this? Is there something else I need to do?
On Sun, 2009-05-31 at 12:31 +0100, Dominic Steinitz wrote:
Dominic Steinitz wrote:
I found this useful - see http://code.haskell.org/asn1/Setup.hs for an example.
Dominic.
Any news on this? Is there something else I need to do?
Sorry, I've been slow in replying. 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. $ runghc Setup.hs configure -v Configuring PER-0.0.20... [..snip..] No asn1c found [..snip..] Using gcc version 4.3.2 found on system at: /usr/bin/gcc [..snip..] Using pdflatex found on system at: /usr/bin/pdflatex [..snip..] Using pdflatex found on system at: /usr/bin/pdflatex Warning: Full inter-operability testing cannot be performed without asn1c Using gcc version 4.3.2 found on system at: /usr/bin/gcc The last three lines are the bits produced by the Setup.hs and the earlier bits are from the normal configure. Duncan
Duncan Coutts wrote:
Sorry, I've been slow in replying.
No problem. I appreciate your response.I realise I am also slow in replying but I only seem to have time at weekends these days.
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? 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 }
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).
perPostConf :: Args -> ConfigFlags -> PackageDescription -> LocalBuildInfo -> IO () perPostConf a cfs pd lbi = do let v = fromFlagOrDefault normal (configVerbosity cfs) pdfSP = simpleProgram "pdflatex" mPdf = lookupProgram pdfSP (withPrograms lbi) asn1cSP = simpleProgram "asn1c" mAsn1c = lookupProgram asn1cSP (withPrograms lbi) cSP = simpleProgram cCompilerName mC = lookupProgram cSP (withPrograms lbi) case mPdf of Nothing -> warn v "Full documentation cannot be built without pdflatex" >> return () Just _ -> do reportProgram v pdfSP mPdf return () case mAsn1c of Nothing -> warn v "Full inter-operability testing cannot be performed without asn1c" >> return ()
Possibly a bit more explanation in the documentation (http://haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple....) would help people like me. Something like "If you want to check for programs then use hookedPrograms and you will get the cabal standard messages. If you want finer control then use lookupProgram and reportProgram e.g. ..." Dominic.
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
participants (2)
-
Dominic Steinitz -
Duncan Coutts