ld-options parsing treats , as separator

[duncan]

Say we've got X11.buildinfo.in:

ld-options: @X_LIBS@ @LDFLAGS@

and imagine that someone has all kinds of crazy LDFLAGS:

LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--hash-style=gnu -Wl,-z,relro -Wl,--as-needed -Wl,-z,now"

Can you guess what happens?

We end up parsing that as:

ldOptions = ["-Wl", "-O1", "-Wl", "--sort-common",
             "-Wl", "--hash-style=gnu",
             "-Wl", "-z", "relro",
             "-Wl", "--as-needed",
             "-Wl", "-z", "now"]

This is because the parser for the ld-options field is defined using listField which uses parseOptCommaList which uses space and ',' as value separators. We should use just spaces for this field and also for cc-options and cpp-options.

If we make this change we'll have to check that we're not going to break things for existing .cabal files that might use ',' as a separator. Will require an audit of .cabal files on hackage.

[duncan]

Turns out all existing .cabal files are fine, none use , as a separator in any of the fields cpp-options, cc-options or ld-options. We can assume that configure scripts that write .buildinfo files do not use it as a separator since they're written by shell scripts which use space as a token separator and also because they're likely getting these options from some tool which would generate them in a format suitable to pass direct to gcc.

Tue Jul 29 18:05:56 BST 2008  Duncan Coutts <duncan@haskell.org>
  * Do not use ',' as a list separator for the cpp/cc/ld-options fields
  It breaks for some options like "ld-options: -Wl,-z,now"
  No existing .cabal files on hackage were using ',' as a
  list separator so this should not break anything.