id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	difficulty	ghcversion	platform
295	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."	defect	closed	normal	Cabal-1.4	Cabal library	HEAD	normal	fixed			normal	6.8.2	
