[Hackage] #264: unionBuildInfo should not always use nub

Hackage trac at galois.com
Wed Apr 2 14:10:55 EDT 2008

#264: unionBuildInfo should not always use nub
  Reporter:  igloo          |        Owner:         
      Type:  defect         |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:
  Severity:  normal         |     Keywords:         
Difficulty:  normal         |   Ghcversion:  6.8.2  
  Platform:                 |  
 The below report was originally filed as

 In libraries/Cabal/Distribution/PackageDescription.hs, the unionBuildInfo
 function combines, for example, ldOptions from two BuildInfos, using nub
 to eliminate duplicate arguments.  This is wrong for ldOptions and some
 other elements.  For example, if ldOptions contains:

 {{{-Xlinker -R -Xlinker /dir1 -Xlinker -R -Xlinker /dir2}}}

 Then the nubbed result is:

 {{{-Xlinker -R /dir1 /dir2}}}

 which doesn't work at all.  There may be some redundancy that could be
 eliminated, but for arguments passed to external programs, it can only be
 done safely by understanding the semantics of the arguments.  Similarly
 for extraLibs, {{{-lfoo -lbar -lfoo}}} may be necessary if {{{libfoo}}}
 and {{{libbar}}} reference each other's symbols.

 Using nub is wrong for at least cppOptions, ccOptions, ldOptions, and
 extraLibs.  But I think it is necessary for some other BuildInfo
 components, like hsSourceDirs, so it can't be removed completely; that
 results in an error while building GHC:

 Preprocessing library unix-
 Generating Makefile unix-
 Setup: makefile: can't cope with multiple hs-source-dirs yet, sorry

 So {{{combine}}} could take an extra arguments, which would be nub in some
 cases or id in others.

Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/264>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list