Hello. some questions and suggestions

[Marc Weber]

Dear Cabal-devel-list reader

I've written two mails to Isaac Jones concerning cabal.
He kindly asked me to use this list. So here I am.

Scroll to the end of this mail to get to the most important text (look for 3) )


1) ------------------------------------------------
first mail with response

Marc Weber <marco-oweber at gmx.de> writes:

> Hi Isaac Jones.

Hi, Marc, thanks for writing.  There's a cabal-devel mailing list
where you can post questions so that others can take a crack at
answering them, and they can get archived on the internet :)

> I wanted to learn more about greencard so I started nivestigating how to
> use greencard preprocessor of cabal. Then I noticed different things
>
> When building a lib and one or more executables only one build-depends
> setting is allowed for all three, lib and executables, right?
> If so it doesn't make much sense as ghc compiles statically so libs will
> be included in all executables which aren't necessary. (Correct me if
> I'm wrong, I feel still like a noob ;)

The build dependencies are on a per-package basis so that we can track
dependencies between packages (for instance, to make sure that
dependency x is installed before package y).  Have you verified that
the so libs are compiled in and bloating unnecessary stuff?  That's
kinda too bad, but I'm not sure offhand what to do about it.  As an
end-user, you can always break things into separate packages.

> Running more than one preprocessor on the same file requires writing
> your own PrePrecossor handler and your own extension?

Yes, we've never done chained preprocessors.  We've been planning it
for a while, as noted on this ticket:
http://hackage.haskell.org/trac/hackage/ticket/13

If you can implement it, that would be great :)

> So I came up with the idea (see post on haskelcafe) to use multiple
> extensions, such as
>
> A.hs.gc.di.chs which should mean:
> run c2hs, DrIft and then Greencard preprocessor on file A.hs.
> + you can read the file extension and you know what's going on
> - long names
> - you have to configure your editor to recognize .gc.di.chs as haskell
>   file
> - You can't test for existing files, you have to list all files in all
>   source directories and remvove those allowed extensions to see wether
>   a file matches a module name.
>
> What do you think?
>
> I've started implementing it and I want to write a test now.

I think that searching for the files is going to be the hard part.
Might not be too bad, though.

> I know I can add my own IO action hook beeing invoked by ./setup test.
> The runTests hook function takes a Bool flag without description. dons
> on #haskell suggested it might be a verbose flag. This would make sense
> as the test hook doesn't take the ConfigFlags argument containing the
> verbose Int setting. So is this the verbose flag and if so why Bool and
> not Int, too?

I can't remember what the Bool in runTest is for, honestly.  Might be
a mistake.  I set up runTest so that you can pass it any flags you
want (see the example in test/withHooks/Setup.lhs).

> When writing tests for cabal packages, how is this done?
>
> I think it does make sense to seperate testing compiler/ package setup
> flavour from the package because not everyone installing the package
> wants to run the tests.
>
> Would it be nice to be able to add test modules in the cabal file such
> like
>
> test-source-dirs: test
> test-is:  MyPackageTest.hs
> test-build-depends: QuickCheck
> test-flavour: ghci
>
> and let cabal handle compiling/ running the test when invoking 
> ./setup test
> automatically?

Maybe we could do that with configurations, as discussed on the
mailing list recently:
http://hackage.haskell.org/trac/hackage/ticket/27

That might be a more general solution, although not implemented yet.

> I think running ghci might be a little bit faster than the compiler.
> This would require adding flavour GHCI for those who don't have hugs
> installed.
>
> Can you tell me more about the status of cabal-install?

It's mostly done, but quite a few loose ends to tie up, and work on
promition and adoption needs to be done.  There's a hackathon planned
where some folks will work on it:

http://www.mail-archive.com/haskell@haskell.org/msg19470.html

Maybe you can join in, or join in remotely :)

peace,

  isaac



------------------------------------------------

2) ------------------------------------------------
response 2:

> Thanks Isaac for your wonderful reply

You're very welcome.  Thanks for your interest in Cabal.  We're always
looking for good hackers :)

>> Hi, Marc, thanks for writing.  There's a cabal-devel mailing list
>> where you can post questions so that others can take a crack at
>> answering them, and they can get archived on the internet :)
>
> I'd like to join, really. Would you mind pointing me to the mailinglist
> you were refering to? I wasn't able to locate it. (neither on
> haskell.org -> mailinglists nor on hackage)
> Is this the right one?
> http://www.haskell.org/mailman/listinfo/libraries

http://www.haskell.org/mailman/listinfo/cabal-devel

The list of haskell mailing lists is here:
http://www.haskell.org/mailman/listinfo/

:)

> I've trouble compiling cabal-install because Network/XmlRpc/Internals.hs seems
> to be in the path of ghc sources only. Is this meant to be used with ghc
> distribution only?

That's an older version of cabal-install.  Look at this repo, it
doesn't require many dependencies:

darcs get http://darcs.haskell.org/cabal-with-install/

I don't know if it works w/ anything but ghc at the moment.

> I like the idea using indentation (such as the haskell language is
> using anyway) Thus either use {;;..} or indentation. Do you know
> wether this processing step can be taken from a haskell compiler
> parser?

Are you referring to the configurations thread?

> As soon as I'll be subscribed to the list I'll repost these messages
> to be archived and read by others.

The archive is here, you don't have to subscribe to read:
http://www.haskell.org/pipermail/cabal-devel/


peace,

  isaac





3) ------------------------------------------------
summary, my steps, suggestions?


Refering to http://hackage.haskell.org/trac/hackage/ticket/13 
(topic allow preprocessor chaining)

	I'm working on this.
	Should be finished soon.


Refering to http://hackage.haskell.org/trac/hackage/ticket/27
(enhancement, configuration option, optional dependencies etc)

	I'd like to work on this too. But I I'm lacking some knowledge here.

	At the moment cabal is using ReadP, right?

	Am I also right that ReadP is lacking user friendly error messages
	compared to parsec?
	
	I like the idea of using either { ; ; } or indentation. Thus you have
	best of both styles, C and python such like the haskell language.

	So would it be ok to use parsec instead of ReadP?

	------- example file
	name: <name of package>
		version: <package version>
		build-depends:

	
	lib: <name of lib>
		hs-source-dirs:
		version: <lib version>
		test: test1 { main-is: test.hs; additional-dependencies: QuickCheck }
		test: test2 { main-is: test2.hs; additional-dependencies: QuickCheck }

	executable: <name of executable>
		hs-source-dirs: executable1
		main-is: Main.hs
		additional-dependencies: <dependencies additional to global package dependencies>
		test: test1 { main-is: test.hs }
	
	executables: executable2 { main-is: Main.hs; hs-source-dirs: ex2 }
	[ ... ]
	-----------------
	^ Notice that you can attach tests to either libraries or executables.
	I would run them using 
		./setup test <executable-name>/<test-name>
		./setup test <executable-name>/*
		./setup test * -- run all tests
	
	Then I would suggest a directory structure like this
	packagedir/
		executable1/
			tests/test1/test.hs
			tests/test2/test.hs
		executable2/
			tests/test1/test.hs
			tests/test2/test.hs
		lib/
			test/test1/test.hs
			test/test2/test.hs
	which would mean setting hs-source-dirs: to the name of executable or library by default
	

	Some thoughts about what to support:
	cross-compiling ? ( I mean ghc can compile via C and gcc can do
	cross-compiling. I've never done this before)

	configuration dependend on
		* os/ compiler flavour eg [configuration: OS=windows, COMPILER=ghc]
		* selected features eg ( --enable-jpeg-support )
		* existance of other libraries ( either gtk2hs or wxhaskell or hscurses ?
						 hsplugins? ( example haskelldb ) )
		* custom flags : flag workaround ghc-windows bug = OS=windows compiler=ghc compiler-version < 4.0
		  does this mean "or" or "and" ? Both should be possible

	as setup.hs has to be compiled anyway, would it be a good idea to not
	just print the configuration to a file (.setup-config), but generate a haskell module
	beeing imported by setup.[l]hs ? This would mean that you can even use haskell-expressions as flags such as
	hasGreencard : executableInPath "greencard" && greencardVersion > (3,2,0)
	[configuration: hasGreencard]
	Thus you can easily use or, and ||, && and so on or `elem` configuration options ...

	This leads me to the assumption that the only difference between
	setup.hs and package.cabal is that it's easier to write a cabal
	file than a module containing the same information, right?
	
	There should be the possibility to only use some configuration option depending on others.
	eg:  ./setup --help
		--use-image-lib1 
			--with-jpg
			--with-gif
		--use-iamge-lib2
			-- no suboptions here
	right?
	
	Things are done in this order right now:

	setup.hs -> tool to 
	   * configure 
	   * build  -- with user hooks
	   * test  -- with user hooks
	   * install
	
	Would it make sense to allow user hooks when configuring, too?
	This would result in a two stage tool chain:
	
	configure.hs -> tool to
	   * configure -- with user hooks (eg generating Config.hs imported by setup.hs)
	setup.hs + configuration options -> tool to
	   * build  -- with user hooks
	   * test  -- with user hooks
	   * install

	What do you think ??
	I have to think about this again.


Yet another thing. This is annoying:
		./setup configure
		./setup build
		sudo ./setup install
	It's like doing
		ebuild `equery which ghc` unpack
		ebuild `equery which ghc` compile
		ebuild `equery which ghc` install
	on gentoo systems

	Is it the task of cabal or cabal-setup to just use
	./setup install
	which should run configure/ build automatically if necessary?
	or at least allow ./setup configure build install (in short ./setup cbi)

Packags containing libraries and executables:
	Am I right that there is no difference in
	a) isntalling lib -> compiling executable with -pacakge lib
	b) compiling executable with lib modules in path.
	as long as there lib is a static lib.
	shared libraries aren't used because of recompilation issues, right?

	It would be much cleaner to use a) in any way and let cabal install the libraries before compiling those executables automatically...

Does it make sense to distribute two libraries usnig one package?
	Example 1: Cabal contains some functionality to join filenames. This might
	also be another package to be used in different applications as well?
	
	Example 2: MissingH. I think it would be best to split this into different libs
	(MissingH-logging, MissingH-Prelude, ...)

Aeh.. Sorry for this long post and happy replying...

Marc Weber