containers.h prevents compilation without cabal

[treeowl]

When I try to compile Data.Sequence, I now get an error that it can't find containers.hs.

[tibbe]

What is containers.hs?

[treeowl]

I mean containers.h. Sorry. It's now #included in Data.Sequence.

[foxik]

The containers.h is now included by all Haskell sources. It defines typeable instances, strictness macros and MIN_VERSION_base if it is undefined.

To compile Sequence.hs from Data directory, just add -I../include. To compile Data/Sequence.hs from the root of the repo, just add -Iinclude.

[tibbe]

This is not really much easier than including -optP-include -optPdist/build/autogen/cabal_macros.h.

[foxik]

Agreed. The containers.h is not there because of cabal-less build. The containers.h contains

• the INSTANCE_TYPEABLEx, which were in Typeable.h header -- that header collided with the Typeable.h header from base in some cases when correct include path was not used, which was the case in tests and in cabal-less builds. This is why I created a header with more unique name.
• the STRICT_x_OF_y macros, which were defined in every file separately
• definition of WORD_SIZE_IN_BITS for GHC
• and lastly, it defines MIN_VERSION_base if it does not exist as a convenience for me, because it is the right place where to put it. But even if it wasn't here, we would still have containers.h.

[treeowl]

It looks like this file is a good idea, but would it be possible to use an explicit path for the #include?

#include "../include/containers.h"

Or would this cause some sort of trouble somewhere?

[foxik]

Having common header file is quite common practice (running find on my packages returns bytestring, directory, primitive, process, unix, vector), as is using include-dirs cabal directive (all the mentioned packages use it). Personally I see no reason why not using it.

What you propose would probably work too, but I am quite satistifed with current (commonly used) solution.