[PATCH] Store licenses in text files instead of code.

[refold]

This shaves 300 KiB off the final executable size and makes it slightly easier to add new license types (just drop the text file under %SRCDIR%/licenses and modify the 'licenseFile' function in Distribution.Client.Init.hs).

[refold]

Posting this as a ticket since my mail to cabal-devel@… seems to be stuck in the moderation queue.

[duncan]

I'm inclined to keep it the way it is. It has the advantage that the cabal binary has no data files so you can move or distribute a cabal executable just on it's own. This is particularly handy for windows where we can (and do) distribute a cabal.exe just as-is.

I don't like the fact that they're embedded in the source code either though. Perhaps we can use a resource mechanism. Windows certainly supports that and we can probably do something similar on unix by adding things into the elf file. OSX has its bundles stuff, or could do the same trick as on ELF systems.

[refold]

ELF equivalent of windres is  elfrc.

If we choose to implement resource file support, it should be also available to the users of Cabal. I propose the following interface:

• A resource-files: field in the .cabal file
• An auto-generated Resources_$packagename.hs file of the following form:

foreign import ccall "&" _imgdata :: CString 

imgdata :: CStringLen
imgdata = (_imgdata, 405585)

[...]

[refold]

Since cabal-install already depends on bytestring, we can then use unsafePackCStringLen and ByteString? I/O functions for outputting the license file.

[refold]

Replying to refold:

Since cabal-install already depends on bytestring, we can then use unsafePackCStringLen and ByteString? I/O functions for outputting the license file.

After looking at how ByteString? I/O is implemented: converting to ByteString? is actually not needed, we can just use hPutBuf.

[duncan]

Yeah, something like that. I was thinking of a slightly more general interface that would allow other/different implementation options on different machines or in different contexts (e.g. debug builds).

Something like, Resources_$packagename.hs:

openResource :: String -> IO Handle

So it's very much like the current Paths_$packagename.hs:

getDataFileName :: FilePath -> IO FilePath

but it combines locating with opening the resource as an ordinary Handle. Doing IO to perform the open and providing a Handle gives us quite a lot of implementation options. We can still do the ELF foreign import ccall "&" stuff or we can use ordinary files (e.g. for debug and I think MacOSX bundles use separate files too), and for Win32 we can use the Windows resource APIs. This relies on the new base-4 Handle stuff which lets you create custom handle implementations.