Re: 64-bit windows version?
Peter Tanski wrote: On Jun 22, 2007, at 11:42 AM, Simon Marlow wrote: Peter Tanski wrote: A bit invasive (it involves modifying the make rules so they take an object-suffix variable). Instead of the current suffix.mk: $(odir_)%.$(way_)o : %.hc it should be: $(odir_)%.$(way_)$(obj_sfx) : %.hc or some such. This may affect other builds, especially if for some reason autoconf can't determine the object-suffix for a platform, which is one reason I suggested a platform-specific settings file. I could handle this by having autoconf set the target variable, put all the windows-specific settings in a settings.mk file (including a suffix.mk copy) and have make include that file. Surely this isn't hard? ifeq $(TargetOS) windows osuf=obj else osuf=o endif and then use $(osuf) wherever necessary. Yes it is easy but now all Makefiles must be changed to use $(osuf), such as this line in rts/Makefile: 378: %.$(way_)o : %.cmm $(H_FILES), for what will be a (hopefully) temporary Windows build. I bet there are only a few makefiles that explicitly refer to o as the object-file suffix. I don't understand why you see this as a temporary measure. Surely we'll need a way to build GHC again for this platform? Unless you intend to replace the whole build system? (which I strongly recommend *not* doing, at least not yet) 4. modify the core packages to use Win32 calls only (no mingw) That is where a lot of preparation is going. This is *much* harder to do from mingw than from VS tools since you have to set up all the paths manually. I don't understand the last sentence - what paths? Perhaps I wasn't clear here: I'm talking about the foreign calls made by the base package and the other core packages; we can't call any functions provided by the mingw C runtime, we can only call Win32 functions. Similarly for the RTS. I have no idea how much needs to change here, but I hope not much. To use the MS tools with the standard C libraries and include directories, I must either gather the environment variables separately and pass them to cl/link on the command line or I must manually add them to my system environment (i.e., modify msys.bat, or the windows environment) so msys will use them in its environment. The other problem is the old no-pathnames-with-spaces in Make, since that must be made to quote all those environment variables when passing them to cl. I could use the Make-trick of filling the spaces with a character and removing that just before quoting but that is a real hack and not very reliable--it breaks $(word ...). Use GHC as your C compiler, i.e. don't invoke CL directory from make, and add the INCLUDE/LIB directories to the RTS's package.conf. Altogether it is a pain to get going and barely reproducible. That is why I suggested simply producing .hc files and building from .hc using VS. Doing an unregisterised build, you mean? Sounds a bit scary! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Jun 25, 2007, at 5:19 AM, Simon Marlow wrote: Yes it is easy but now all Makefiles must be changed to use $ (osuf), such as this line in rts/Makefile: 378: %.$(way_)o : %.cmm $(H_FILES), for what will be a (hopefully) temporary Windows build. I bet there are only a few makefiles that explicitly refer to o as the object-file suffix. After poking around I found that my fears were unfounded. Simply pass cl the /TC (or -TC) option--same as the gcc option '-x c'. Object files are also fine since cl assumes any file with an unrecognised suffix is an object file. The environment variables problem is also solved: either have the environment set up automatically by placing a batch-script 'call' to the MS PSDK 'SetEnv.Cmd' before the shell login in msys.bat or start the DOS shell from the MS PSDK shortcut and log into the msys shell manually--or run the whole thing from DOS. Shows how much I know of msys. Passing flags to cl would be best in a command file (at least I have done _that_ before). I don't understand why you see this as a temporary measure. Surely we'll need a way to build GHC again for this platform? Unless you intend to replace the whole build system? (which I strongly recommend *not* doing, at least not yet) I keep on referring to this as temporary because there are two different builds here: (1) the build using the old mingw-GHC, without option support for CL; and, (2) the build using the new Windows-native GHC. You will almost certainly keep mingw-GHC around but users should not have to download a mingw-GHC to build Windows-native from source (they can't start at a stage1 build), so the Windows-native requires a separate setup. That might as well be Windows-native itself, in other words, use VS--it is the quickest and easiest build to put together. I do not suggest CMake because CMake is a sledgehammer when it comes to managing projects and sub-projects: all paths are absolute (you cannot move the source directories around), there is only one major Project in a system--it only really builds 'all', not sub-targets and build variants beyond the buitin Debug, MinSizeRel, Release, etc., have to be custom-added; it would not integrate well with the current $(way) system. If you are heavily against using VS, maybe an Eclipse/Ant-based build would do. I might use Bakefile. It would be much better to have a single build system. I would gladly replace the whole thing for three reasons: (1) it is a source of many build bugs and it makes them much more difficult to track down; and, (2) it seems to be a serious hurdle for anyone who wants to build and hack on GHC--this is true for most other compiler systems that use the autoconf and Make; and, (3) if GHC is ever going to have cross-compilation abilities itself, the current build system must go, while cross-compiling GHC with the current system requires access to the actual host-system hardware. The reasons I don't are: (1) time (parallel to money); (2) I wouldn't undertake such an effort unless we were all pretty sure what you want to change the build system to; (3) an inevitable side-effect of the move would be loss of old (or little-used) build settings, such as GranSim, and a change to the build system would propagate to parallel projects; and, (4) it is a huge project: both the compiler and libraries must change and the change must integrate with the Cabal system. Work on the mingw-make system is progressing fairly well. The reason to make a special VS build are: (1) Windows programmer familiarity; (2) reduction in the number of build bugs; (3) ease of extension or integration with other VS tools, such as .NET; and, (4) speed--VS builds are much faster than Make. I should also add that when building the RTS it is simply much easier to have a build problem reported in VS than search back through Make- output and manually go to the offending line in a source file. The reason not to make a special VS build is you would have to support it--one more thing to check when new source files are added. As I said before, this may be scripted and if Windows programmers have something familiar to work with there may be more of them to help. (You probably have better reasons than that one.) Use GHC as your C compiler, i.e. don't invoke CL directory from make, and add the INCLUDE/LIB directories to the RTS's package.conf. Certainly doable but it does present a conundrum: for the old GHC (without builtin cl-support) the order for compilation seems to be: compile/link command compile/link flags output source/object files other flags while for cl running link.exe or link.exe, it is better to put all the files at the end of the command line: compile/link command compile/link flags output other flags source/object files It also adds one more layer of indirection a that delicate stage. I am in the process of modifying and testing
Re: 64-bit windows version?
On Mon, 2007-06-25 at 11:43 -0400, Peter Tanski wrote: It would be much better to have a single build system. I would gladly replace the whole thing for three reasons: (1) it is a source of many build bugs and it makes them much more difficult to track down; and, (2) it seems to be a serious hurdle for anyone who wants to build and hack on GHC--this is true for most other compiler systems that use the autoconf and Make; and, (3) if GHC is ever going to have cross-compilation abilities itself, the current build system must go, while cross-compiling GHC with the current system requires access to the actual host-system hardware. The reasons I don't are: (1) time (parallel to money); (2) I wouldn't undertake such an effort unless we were all pretty sure what you want to change the build system to; (3) an inevitable side-effect of the move would be loss of old (or little-used) build settings, such as GranSim, and a change to the build system would propagate to parallel projects; and, (4) it is a huge project: both the compiler and libraries must change and the change must integrate with the Cabal system. I am thinking of starting a new project (possibly as sourceforge) to implement a new build system. I think Erick Tryzelaar might also be interested. The rule would be: it isn't just for GHC. So any interested people would have to thrash out what to implement it in, and the overall requirements and design ideas. My basic idea is that it should be generic and package based, that is, it does NOT include special purpose tools as might be required to build, say, Haskell programs: these are represented by 'plugin' components. A rough model of this: think Debian package manager, but for source code not binaries. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Tue, 26 Jun 2007 02:06:25 +1000 skaller [EMAIL PROTECTED] wrote: My basic idea is that it should be generic and package based, that is, it does NOT include special purpose tools as might be required to build, say, Haskell programs: these are represented by 'plugin' components. Have you seen Aap (http://www.a-a-p.org/) ? Sincerely, Gour signature.asc Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
need help with 6.4.2 boot build for hpux 11.0
I am attempting to get 6.4.2 booted under hpux 11.0 following the instructions for building from hc files generated on another machine. The target compiler builds but will not build a trivial test program. The error message indicates that it cannot import the Prelude module. Looking at the system calls that the compiler is making I am guessing that package.conf.inplace is not correct. The one produced by the target build is basically empty, as compared to the one on the host machine. Can this file just be copied from the host build machine to the target? Another question I have is this, is there a better version of GHC to try this with? The instructions don't match the 6.6 source tree layout so I went back to 6.4.x. I have had to install some patches though so am wondering if I would have an easier time of this with something even earlier? -- Joe Buehler ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Jun 25, 2007, at 12:06 PM, skaller wrote: On Mon, 2007-06-25 at 11:43 -0400, Peter Tanski wrote: It would be much better to have a single build system. I would gladly replace the whole thing ... I am thinking of starting a new project (possibly as sourceforge) to implement a new build system. I think Erick Tryzelaar might also be interested. The rule would be: it isn't just for GHC. So any interested people would have to thrash out what to implement it in, and the overall requirements and design ideas. My basic idea is that it should be generic and package based, that is, it does NOT include special purpose tools as might be required to build, say, Haskell programs: these are represented by 'plugin' components. A rough model of this: think Debian package manager, but for source code not binaries. I have been considering the same thing for some time, partly because the specification properties of most available build systems are terrible: XML is not a language (it is better as a back-end for a gui- based build system); current plug-in systems (similar to what WAF uses) are object-oriented and require a deep knowledge of the build system API; others are manual hacks. One big thing to avoid are cache-files: CMake, SCons, WAF, autotools, all use cache-files and all run into problems when the cache files aren't cleaned or include errors. (WAF has the best cache-file system--they are designed to be human-readable.) I will gladly lend support to this. An idea I have been kicking around is a hybrid between the autoconf strategy and the commercial-setup strategy: add support for a specification of program requirements, i.e., stdint.h, gcc/cl/icl, things like that in a simple spec-document with dead-simple syntax, then let the build system handle the rest--it would know what to do for each architecture. That seems similar to the Debian package maker, right? What language are you thinking about using? Scheme seems good but the build-language itself might be different; gui-support should be available which says to me (horrors!) Java AWT--a cross-platform gui- supported build system (not an IDE) would rock the world because it doesn't exist. There are tons of Python packages out there (A-A-P, hasn't been updated since 2003; SCons, WAF, Bakefile (uses Python)). I don't know if this is possible in Felix. Other requirements might be: (1) never alter anything in the source directories--everything is managed through the build directory (2) ability to easily build separate targets from the command line, similar to 'make test_shifts'--externally scriptable. One thing other systems seem to fail at is building off the enormous trove of information in autoconf--it's right there, open source, and they reinvent the wheel when it comes to making configuration tests or finding platform information (config.guess is essentially a database of platform-specific information but is somewhat dated with regard to newer systems, including OS X). On that note, a different approach to configuration tests might be clearer knowledge about the compilers: all these systems build small C programs to test certain compiler characteristics and test for a 0 exit value. Well, CMake does actually 'read' the output files for some things, such as compiler version. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
Certainly doable but it does present a conundrum: for the old GHC (without builtin cl-support) the order for compilation seems to be: compile/link command compile/link flags output source/object files other flags while for cl running link.exe or link.exe, it is better to put all the files at the end of the command line: compile/link command compile/link flags output other flags source/object files It also adds one more layer of indirection a that delicate stage. Maybe some gcc mimicing cl wrapper tailored specifically for GHC building system could help? One more layer of indirection, but could leave ghc driver relatively intact. Cheers, Kyra ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Jun 25, 2007, at 12:55 PM, kyra wrote: Certainly doable but it does present a conundrum: for the old GHC (without builtin cl-support) the order for compilation seems to be: compile/link command compile/link flags output source/ object files other flags while for cl running link.exe or link.exe, it is better to put all the files at the end of the command line: compile/link command compile/link flags output other flags source/object files It also adds one more layer of indirection a that delicate stage. Maybe some gcc mimicing cl wrapper tailored specifically for GHC building system could help? One more layer of indirection, but could leave ghc driver relatively intact. That's a good idea! Do you know if or how the mingw-gcc is able to do that? Does mingw-gcc wrap link.exe? It sounds silly that someone relatively inexperienced with mingw should be doing this but it _really_needs doing and no one else seems to want it (besides, from my perspective, once I get through the build-system drudgery it lets me handle the fun stuff like adding inline MASM to the RTS, such as ghc/includes/SMP.h). Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Mon, 2007-06-25 at 13:35 -0400, Peter Tanski wrote: Maybe some gcc mimicing cl wrapper tailored specifically for GHC building system could help? One more layer of indirection, but could leave ghc driver relatively intact. That's a good idea! Do you know if or how the mingw-gcc is able to do that? Does mingw-gcc wrap link.exe? There's more to portable building than the build system. For example, for C code, you need a system of macros to support void MYLIB_EXTERN f(); where MYLIB_EXTERN can be empty, say __declspec(dllexport) on Windows when building a DLL, and __declspec(dllimport) when using it. This is *mandatory*. The build system controls the command line switches that turn on We're building a DLL flag. A distinct macro is needed for every DLL. In Felix, there is another switch which tells the source if the code is being built for static linkage or not: some macros change when you're linking symbols statically compared to using dlsym().. it's messy: the build system manages that too. Building Ocaml, you have a choice of native or bytecode, and there are some differences. Probably many such things for each and every language and variation of just about anything .. eg OSX supports two kinds of dynamic libraries. The point is that a 'Unix' oriented build script probably can't be adapted: Unix is different to Windows. The best way to adapt to Windows is to use Cygwin.. if you want a Windows native system, you have to build in the Windows way and make Windows choices. A silly example of that is that (at least in the past) Unix lets you link at link time against a shared library, whereas Windows requires to link against a static thunk .. so building a shared library produces TWO outputs on Windows. OTOH, Unix has this woeful habit of naming shared libraries like libxxx.so.1.2 which really makes a complete mess of build systems. What I'm saying is you just can't wrap Windows tools inside a Unix build script. You have to write an abstract script, and implement the abstractions for each platform. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: 64-bit windows version?
Hello Peter, Monday, June 25, 2007, 9:35:31 PM, you wrote: Maybe some gcc mimicing cl wrapper tailored specifically for GHC building system could help? One more layer of indirection, but could leave ghc driver relatively intact. That's a good idea! there is possibility that such driver was already implemented somewhere i remember old good says when symantec c++ contained such drivers for emulation of CL and BCC :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Jun 25, 2007, at 3:34 PM, skaller wrote: On Mon, 2007-06-25 at 13:35 -0400, Peter Tanski wrote: Maybe some gcc mimicing cl wrapper tailored specifically for GHC building system could help? One more layer of indirection, but could leave ghc driver relatively intact. That's a good idea! Do you know if or how the mingw-gcc is able to do that? Does mingw-gcc wrap link.exe? There's more to portable building than the build system. For example, for C code, you need a system of macros to support void MYLIB_EXTERN f(); where MYLIB_EXTERN can be empty, say __declspec(dllexport) on Windows when building a DLL, and __declspec(dllimport) when using it. This is *mandatory*. Of course--one thing I would add to a build system, instead of compiling little C files and testing the return value to detect some compiler functionality, is the ability to read builtin macros, say, by telling the compiler to dump all macros like 'gcc -E -dM' and then read through the macros. As for the Windows-native build, I am pretty far long with that but the idea was to hijack the gcc executable with a script that would convert the gcc arguments to cl arguments. The one thing such a script would not do is compile everything at once. So far that is one thing I am adding to the Make system here: since dependancy generation is good for Haskell files but is not necessary for C files since I can bunch the C sources together with the compiler flags and pass them cl all at once in a command file. This should be faster than Make. The build system controls the command line switches that turn on We're building a DLL flag. A distinct macro is needed for every DLL. That is part of the modifications to the runtime system (RTS). In Felix, there is another switch which tells the source if the code is being built for static linkage or not: some macros change when you're linking symbols statically compared to using dlsym().. it's messy: the build system manages that too. Sometimes this is better in header files and change the macros with defines the build system passes to the c compiler but Felix's system is much more flexible than that (it builds the source files as interscript extracts them, right?). Building Ocaml, you have a choice of native or bytecode, and there are some differences. Probably many such things for each and every language and variation of just about anything .. eg OSX supports two kinds of dynamic libraries. GHC's interpreter (GHCi) does have to be built. I have not found a libReadline DLL, but I am sure I can scrounge something--possibly from Python since they had this same problem back around 2000. The point is that a 'Unix' oriented build script probably can't be adapted: Unix is different to Windows. The best way to adapt to Windows is to use Cygwin.. if you want a Windows native system, you have to build in the Windows way and make Windows choices. A silly example of that is that (at least in the past) Unix lets you link at link time against a shared library, whereas Windows requires to link against a static thunk .. so building a shared library produces TWO outputs on Windows. I am building with Mingw because that is better supported by the GHC build system (Cygwin is somewhat defunct); the end result should build from source in Visual Studio/Visual C++ Express. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
