
Hello Guys, I have started to extend Cabal with new feature. What I need is to have multiple Haskell source directories for one package. This feature is not substantial if you are packaging library, since it is supposed to have hierarchical namespace, but it is useful if you have executable. It is not mandatory to have hierarchical namespace for executables but if you are using flat namespace then with Cabal you will be restricted to keep all your source files in single directory. The extension that I have in mind will allow to break this restriction. GHC source tree is a good example of such type of project. It uses flat namespace but its source files are separated in multiple directories. The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility. I would like to hear any suggestions or objections against this extensions. I don't want to waste my time if this extension will not be accepted. Cheers, Krasimir

At a tangent to what Krasimir said:
The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility.
I was thinking yesterday about whether it would be possible to extend Cabal's parser to allow different spellings for the individual field names in the .cabal file? Krasimir's example of backward-compatibility is one use-case. For myself, I was wondering about internationalisation, e.g. "license" is spelled "licence" in English, "author" is spelled "auteur" in French, etc. AFAICS, it would be reasonably straightforward to change the type of StanzaField { fieldName :: String, ... } to StanzaField { fieldName :: [String], ... } Regards, Malcolm

I think it is better to keep the package description format simpler.
Something like "auteur" doesn't mean anything for me. As Bulgarian
speaker I would like to use "автор" and "лиценз" instead but this will
be even more confusing for other folks. For a while I just added
simple check for "hs-source-dir" in ParseUtils.mkStanza.
Cheers,
Krasimir
On 5/12/05, Malcolm Wallace
At a tangent to what Krasimir said:
The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility.
I was thinking yesterday about whether it would be possible to extend Cabal's parser to allow different spellings for the individual field names in the .cabal file? Krasimir's example of backward-compatibility is one use-case. For myself, I was wondering about internationalisation, e.g. "license" is spelled "licence" in English, "author" is spelled "auteur" in French, etc.
AFAICS, it would be reasonably straightforward to change the type of StanzaField { fieldName :: String, ... } to StanzaField { fieldName :: [String], ... }
Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 12/05/05, Malcolm Wallace
At a tangent to what Krasimir said:
The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility.
I was thinking yesterday about whether it would be possible to extend Cabal's parser to allow different spellings for the individual field names in the .cabal file? Krasimir's example of backward-compatibility is one use-case. For myself, I was wondering about internationalisation, e.g. "license" is spelled "licence" in English, "author" is spelled "auteur" in French, etc.
Which language is it spelled "license" in? Anyway, even in English there are a lot of differences between the US and the UK.

On 12/05/05, Samuel Bronson
On 12/05/05, Malcolm Wallace
wrote: At a tangent to what Krasimir said:
The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility.
I was thinking yesterday about whether it would be possible to extend Cabal's parser to allow different spellings for the individual field names in the .cabal file? Krasimir's example of backward-compatibility is one use-case. For myself, I was wondering about internationalisation, e.g. "license" is spelled "licence" in English, "author" is spelled "auteur" in French, etc.
Which language is it spelled "license" in? Anyway, even in English there are a lot of differences between the US and the UK.
The Oxford English Dictionary and Merriam-Webster each give both spellings: "license" and "licence".

Cale Gibbard wrote:
Which language is it spelled "license" in? Anyway, even in English there are a lot of differences between the US and the UK.
The Oxford English Dictionary and Merriam-Webster each give both spellings: "license" and "licence".
In the British dialect, the noun is "licence" while the verb is
"license". The US dialect uses "license" for both.
--
Glynn Clements

Hi Krasimir, I don't mind this change much, it might even be good. One thing I like about the old way, though, is that it encourages people to use the hierarchical namespace, which is a nice way to organize things whether you are building a library or an executable. But Cabal's purpose is to help folks build tools, not to enforce style ;) I'd accept it if you feel that you need it. Anyone else have an opinion? peace isaac

On Thu, May 12, 2005 at 09:41:01AM +0100, Krasimir Angelov wrote:
Hello Guys,
I have started to extend Cabal with new feature. What I need is to have multiple Haskell source directories for one package. This feature is not substantial if you are packaging library, since it is supposed to have hierarchical namespace, but it is useful if you have executable. It is not mandatory to have hierarchical namespace for executables but if you are using flat namespace then with Cabal you will be restricted to keep all your source files in single directory. The extension that I have in mind will allow to break this restriction. GHC source tree is a good example of such type of project. It uses flat namespace but its source files are separated in multiple directories. The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility. I would like to hear any suggestions or objections against this extensions. I don't want to waste my time if this extension will not be accepted.
Yes. I often compose projects out of several subprojects and this feature would be needed to place them under cabal. So double++ from me for this idea. John -- John Meacham - ⑆repetae.net⑆john⑈

I have committed the patch. Most of the changes are trivial and I
don't expect unusual behaviour from Cabal after the changes. Let me
know if you have any troubles with it.
Cheers,
Krasimir
On 5/12/05, Krasimir Angelov
Hello Guys,
I have started to extend Cabal with new feature. What I need is to have multiple Haskell source directories for one package. This feature is not substantial if you are packaging library, since it is supposed to have hierarchical namespace, but it is useful if you have executable. It is not mandatory to have hierarchical namespace for executables but if you are using flat namespace then with Cabal you will be restricted to keep all your source files in single directory. The extension that I have in mind will allow to break this restriction. GHC source tree is a good example of such type of project. It uses flat namespace but its source files are separated in multiple directories. The only visible change that is required is to replace hs-source-dir field to hs-source-dirs where the latter will accept a list of directories. The parser can still accept hs-source-dir for backward compatibility. I would like to hear any suggestions or objections against this extensions. I don't want to waste my time if this extension will not be accepted.
Cheers, Krasimir
participants (7)
-
Cale Gibbard
-
Glynn Clements
-
Isaac Jones
-
John Meacham
-
Krasimir Angelov
-
Malcolm Wallace
-
Samuel Bronson