Ticket #849 (new enhancement)

Opened 2 years ago

Last modified 15 months ago

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

Reported by: refold Owned by:
Priority: normal Milestone: cabal-install-0.16
Component: cabal-install tool Version: HEAD
Severity: normal Keywords:
Cc: Difficulty: unknown
GHC Version: Platform:

Description

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).

Attachments

Change History

Changed 2 years ago by refold

  Changed 2 years ago by refold

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

  Changed 2 years ago by refold

  • type changed from defect to enhancement

  Changed 2 years ago by refold

  • version changed from 1.8.0.6 to HEAD
  • component changed from Cabal library to cabal-install tool

  Changed 2 years ago by 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.

  Changed 2 years ago by 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)

[...]

follow-up: ↓ 7   Changed 2 years ago by refold

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

in reply to: ↑ 6   Changed 2 years ago by 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.

  Changed 2 years ago by 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.

  Changed 15 months ago by kosmikus

  • milestone set to cabal-install-0.16
Note: See TracTickets for help on using tickets.