RE: FW: Library infrastructure
Some people have mentioned other systems that might be relevant: the BSD ports tree, CPAN, etc. I'd just like to clarify what (IMHO) we're not aiming for here: in particular, we don't need a system that - downloads source - manages dependencies (beyond what the compiler needs to know) And I'd argue that we don't even need a system that builds binary distributions. The reason is that these tasks are all handled by the various OS package systems: BSD ports, RPM, apt-get, emerge, and so on. We don't want to duplicate or worse, bypass, the local package management system. We do need a system that helps you generate compliant package skeletons in the local native format: an RPM spec, a BSD ports Makefile, or a Gentoo ebuild. Cheers, Simon
* Simon Marlow
We do need a system that helps you generate compliant package skeletons in the local native format: an RPM spec, a BSD ports Makefile, or a Gentoo ebuild.
For FreeBSD ports, I am willing to help.
I have plans, but not yet enough time, to set up a website about
"Haskell on FreeBSD"[1]. I want to provide packages with different
options enabled, since the FreeBSD port build cluster only provides
packages with the default option enabled.
I can also provide information about making FreeBSD ports.
For the time being, please feel free to drop me a note for anything
which should be part of the FreeBSD ports tree.
Regards,
Olli
1. http://haskell.org/freebsd/
--
Oliver Braun ::
Python seems to have a very promising approach to this same issue which is (IMO) more in line with what SimonPJ and SimonMar have said. I don't really use Python much, though so don't count on my being 100% correct here: http://www.python.org/sigs/distutils-sig/doc/ In particular, see the requirements of this system below [1]. Based on the post I'm replying to, Simon Marlow might disagree with some of these requirements, and distutils doesn't seem to implement anything having to do with selecting compilers. HMake could help fill in the gap there. There might be a "bootstrapping" issue here that isn't an issue with Python since a "Setup.hs" script won't necessarily know which compiler is installed. One solution is for the compilers to standardized on something like "/usr/bin/runhaskell", but then the user would need a way to choose a default. "hmake interactive" might get us there, if there were a way to invoke it like runhugs, and hmake already has the idea of a default compiler. peace, isaac [1] "The proposed Module Distribution Utilities for Python, or distutils for short, are needed to fill a number of long-standing holes in the Python distribution and culture. In roughly decreasing order of priority: * There must be an easy, standardized way for users and administrators to add new modules (including extension modules) to an existing Python installation on any platform supported by Python itself. * There must be an easy, standardized way to characterize "meta-data" about a module distribution such as its name, version number, area of applicability, description, and so forth, for the use of indexing and search tools. * There must be an easy, standardized way to create "built distributions" (ready-to-install downloadable resources, with all compilation and other processing done) for the major platforms. * Module distributions must have a standardized way to express their dependencies on other modules (both simple presence/absence and required version number) and on Python itself (version number), and these dependencies must be checked at setup/build/install time. * It must be possible (and preferably easy) to instead download and build from a source distribution. (Necessary for people who don't happen to be using one of the major platforms, or who don't trust built distributions.) * To aid in installing all modules, and in building extension modules from C/C++ source, there must be a standardized way to get Python's configuration data (such as compiler, compiler flags, platform, default library directory, etc.). * It must be easy for a module developer to create both source and built distributions. * It must be easy for a third party (the "packager") to download a source distribution, build it on a particular platform, and create a built distribution for that platform which can then be trivially used by less sophisticated users of that platform. "
tor 2003-04-24 klockan 04.19 skrev Isaac Jones:
Python seems to have a very promising approach to this same issue which is (IMO) more in line with what SimonPJ and SimonMar have said. I don't really use Python much, though so don't count on my being 100% correct here: http://www.python.org/sigs/distutils-sig/doc/
Indeed, distutils is great. I have written pure python modules and C extension modules, and mixed modules, and it all works like a charm. Plus, you have the full power of python in your setup.py script so you can do lots of neat things.
In particular, see the requirements of this system below [1]. Based on the post I'm replying to, Simon Marlow might disagree with some of these requirements, and distutils doesn't seem to implement anything having to do with selecting compilers. HMake could help fill in the gap there.
What do you mean distutils not selecting compilers? It finds gcc on my linux machine and on Solaris, and I think it probes for some windows compilers too. I don't know about e.g. macos.
There might be a "bootstrapping" issue here that isn't an issue with Python since a "Setup.hs" script won't necessarily know which compiler is installed. One solution is for the compilers to standardized on something like "/usr/bin/runhaskell", but then the user would need a way to choose a default. "hmake interactive" might get us there, if there were a way to invoke it like runhugs, and hmake already has the idea of a default compiler.
Not all compilers *have* an interactive mode, do they? I thought nhc98 was just a compiler? This makes it tricky. Another problem is that when you run 'hugs File.hs' or 'ghci File.hs', they start interactive mode, 'python file.py' runs the program. Are there flags to all interpreters that run main automatically? I know there's runhugs for example, but what about ghc(i)? What about nhc98? /Martin -- Martin Sjögren sjogren@debian.org -- marvin@dum.chalmers.se GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html let hello = "hello" : hello in putStr (unlines hello)
Martin Sjögren
There might be a "bootstrapping" issue here that isn't an issue with Python since a "Setup.hs" script won't necessarily know which compiler is installed. One solution is for the compilers to standardized on something like "/usr/bin/runhaskell", but then the user would need a way to choose a default. "hmake interactive" might get us there, if there were a way to invoke it like runhugs, and hmake already has the idea of a default compiler.
Not all compilers *have* an interactive mode, do they? I thought nhc98 was just a compiler? This makes it tricky.
No problem - just a little shell script that does
nhc98 foo.hs -o foo
./foo
would be fine. The interactivity isn't really needed.
--KW 8-)
--
Keith Wansbrough
Martin Sjögren
What do you mean distutils not selecting compilers? It finds gcc on my linux machine and on Solaris, and I think it probes for some windows compilers too. I don't know about e.g. macos.
Ahh, good to hear. A dist-utils style infrastructure is starting to sound even better. Plus Python provides us something that we could model the Haskell version from.
Not all compilers *have* an interactive mode, do they? I thought nhc98 was just a compiler? This makes it tricky.
But hmake interactive ("hi") sorta fixes this by providing a common interactive interface to different compilers / interpreters.
Another problem is that when you run 'hugs File.hs' or 'ghci File.hs', they start interactive mode, 'python file.py' runs the program. Are there flags to all interpreters that run main automatically? I know there's runhugs for example, but what about ghc(i)? What about nhc98?
As others have said, it could be easy to wrap this behavior by compiling and running the program, and in particular, it seems to me that hmake (or the system that Henrik Nilsson mentioned) could provide some kind of /usr/bin/haskell interface much as it provides its hmake interactive interface. Maybe a /usr/bin/haskell interface could look for a "main" function in module Main (as runhugs does) and / or a "setup" or "main" functions in module Setup. Does anyone think that dist-utils is not like what we want? Like I said, I don't have deep experience with it. peace, isaac
Isaac Jones
There might be a "bootstrapping" issue here that isn't an issue with Python since a "Setup.hs" script won't necessarily know which compiler is installed. One solution is for the compilers to standardized on something like "/usr/bin/runhaskell", but then the user would need a way to choose a default. "hmake interactive" might get us there, if there were a way to invoke it like runhugs, and hmake already has the idea of a default compiler.
Well, the following works fine hmake Setup -- use default Haskell compiler to build script ./Setup -- run the script provided that your default Haskell system is not Hugs. Hmmm, maybe we could tweak hmake to accept Hugs as a sort-of compiler, producing a runnable shell-script as the "executable". The shell script would simply invoke runhugs with whatever options were specified for the "build". Regards, Malcolm
Hi, Malcolm Wallace wrote:
Well, the following works fine
hmake Setup -- use default Haskell compiler to build script ./Setup -- run the script
provided that your default Haskell system is not Hugs. Hmmm, maybe we could tweak hmake to accept Hugs as a sort-of compiler, producing a runnable shell-script as the "executable". The shell script would simply invoke runhugs with whatever options were specified for the "build".
We at Yale have been developing a Make-based build system aiming at taking the pain out of building for any combination of Haskell system/OS platform. It's not perfect, nor quite ready, but it works reasonably well. Except for some annoying issues on Wondows platforms ... Anyway, we took the above mentioned approach for Hugs. And not only that, our build system also takes care of any prerequisite preprocessing/auxiliary compilation (CPP, arrowp, GreenCard, what have you), thus effectively building "pure" Haskell code for the library/application in question, which then can be installed and run without any further fuss/passing complicated options to Hugs/requiring the end user to install all necessary preprocessors.
From this perspective, Hugs is not so different from other Haskell systems.
Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu
Henrik Nilsson
We at Yale have been developing a Make-based build system aiming at taking the pain out of building for any combination of Haskell system/OS platform. It's not perfect, nor quite ready, but it works reasonably well. Except for some annoying issues on Wondows platforms ...
I would be interested to know what were the main difficulties you perceived with hmake (apart from its current non-support of Hugs).
And not only that, our build system also takes care of any prerequisite preprocessing/auxiliary compilation (CPP, arrowp, GreenCard, what have you), thus effectively building "pure" Haskell code for the library/application in question,
Many pre-processors are also supported by hmake, and it is easy to add new ones. Regards, Malcolm
Malcolm Wallace wrote:
I would be interested to know what were the main difficulties you perceived with hmake (apart from its current non-support of Hugs).
Well, the non-support for Hugs is an important point. We also wanted support for mixed-language builds, i.e. parts of a system written in C/C++ or Java. We wanted support for installation and building of distributions (source distributions, binary distributions with installation support, RPMs, ...). We wanted support for building documentation of various forms. Our impression was that hmake is an excellent tool for what it does, but that it just was not intended for doing all we wanted it to do. That said, maybe a mixed make/hmake build system might have been better than our current make-only system, except, of course, that hmake then would be yet another tool the end user would need to install to get going.
Many pre-processors are also supported by hmake, and it is easy to add new ones.
How? By scripting hmake through some kind of hmake file? Or by changing the source? The latter would not really be quite good enough in my opinion, since one may want to support non-standard pre-processors for some particular project. Distributing a tailor-made hmake for that purpose, and thus potentially forcing the end user to install and manage multiple hmake-versions at the same time, does not seem very appealing. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu
Henrik Nilsson
Well, the non-support for Hugs is an important point. We also wanted support for mixed-language builds, i.e. parts of a system written in C/C++ or Java. We wanted support for installation and building of distributions (source distributions, binary distributions with installation support, RPMs, ...). We wanted support for building documentation of various forms.
I agree that hmake is not intended for most of those tasks. It just builds software written in Haskell.
That said, maybe a mixed make/hmake build system might have been better than our current make-only system, except, of course, that hmake then would be yet another tool the end user would need to install to get going.
You are probably already requiring the end user to install a Haskell compiler/interpreter, a C/Java compiler, and a documentation tool (LaTeX, Haddock, DocBook, whatever).
Many pre-processors are also supported by hmake, and it is easy to add new ones.
How? By scripting hmake through some kind of hmake file? Or by changing the source? The latter would not really be quite good enough in my opinion, since one may want to support non-standard pre-processors for some particular project.
At the moment, indeed you need to change the sources. However, I have been playing for a long time with the idea of detecting/configuring pre-processors externally in much the same way that compilers are currently detected/configured. I'm sure it wouldn't be too hard. If there is enough demand I'll probably do it. Regards, Malcolm
Hi, Malcolm Wallace wrote:
You are probably already requiring the end user to install a Haskell compiler/interpreter, a C/Java compiler, and a documentation tool (LaTeX, Haddock, DocBook, whatever).
Yes, one tool/library more or less to install is not going to make much of a difference, I suppose.
At the moment, indeed you need to change the sources. However, I have been playing for a long time with the idea of detecting/configuring pre-processors externally in much the same way that compilers are currently detected/configured. I'm sure it wouldn't be too hard. If there is enough demand I'll probably do it.
That sounds like a good idea to me! In particular if it is easy to do. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu
participants (7)
-
Henrik Nilsson -
Isaac Jones -
Keith Wansbrough -
Malcolm Wallace -
Martin Sjögren -
Oliver Braun -
Simon Marlow