Hi Hiro, On Mon, 19 Nov 2001 13:39:18 -0600 (CST) Hironori Ito <hito@students.phsx.ukans.edu> wrote concerning "ROOT on windows98 or 2000 ????": > Hello. I have a question to someone who are bored enought to read > this message. If you are already bored, just delete this message > now. Anyway, I am interested in to run ROOT on a MS WIN machine. Do > anyone succeed doing so without VC++? ROOT seemed to have an option for > win32egcs, and I have gcc/egcs with cygwin. But, I can not get it > work. Anyone??? You're best bet on reliant information, is as Konstantin pointed out, Valerie Fine of STAR. Last spring, he was at the far end (from the HIRG corridor) of STAR groundlevel corridor. I've talked to him a couple of times, and he's very friendly and helpful. Kris points out, that in principel, you should be able to compile ROOT with GCC under Cygwin. In principel he's right. However, the last time I checked, which is some time ago I should say, I did not work. The short version of the story is, that ROOT assumes too much based on the configuration architecture, and that Cygwin does not porvide a full Posix/X11 environment. This interplay makes it hard, if not impossible, to build ROOT with Cygwin. Let me try and be a bit more exact: * If you configure the ROOT source tree with option "linux", then the preprocessor flags like R__UNIX, and so on is defined. This is all well and fine :-) for most stuff, but for certain things both in CINT and ROOT proper, it fails - that flag is simply not good enough for Cygwin. * Some Posix features are not fully supported by Cygwin. ROOT obviously assumes a Posix environment if the preprocessor flag R__UNIX is defined. But that breaks under Cygwin occationally. * The worst part is Graphics. Either, one should use the Win32 stuff that is in ROOT, or one should use X11. Fons seem to prefer the later in case of Cygwin. The X11 story could be looking brighter now that it seems X11 has been ported to Cygwin. My problem was probably that I was running WinNT from within Vmware on a Linux box (it's not Linux, but Vmware and X11 on Cygwin that caused the problems). I tried back then to make the port, but sort of gave up when I found out just how many changes I needed to make. If you feel you have the time, then by all means make the port - but be advised that it's not a two-three day job - more like 1-2 weeks (if not more). Now, in terms of BRAT. If you can compile ROOT with Cygwin, you can also compile BRAT with Cygwin. You may have to build MySQL for Cygwin too, but that I think is already done. Anyway, you need to port ROOT to Cygwin, and I'm pretty confident that you need to port nothing else. As to the use of Autotools. Autotools is indeed a part of Cygwin version 1+ [1]. The only thing that's missing from that list, is Libtool. However, that can be build from source directly under Cygwin (I did it once) [2]. As for Autotools and M$VC. What I said was possible when I argumented for Autotools was: ... Ok, I was about to insert a quote here, but I couldn't find the relevant mail in the archive in my own file. Hmm. Well. The situation is this, as I wrote to Richard Kreckel and Masa Goto, and I'm farily certain (I don't have the mail to prove it though) I also wrote back when Flemming, Kris and I was dicussion the BRAT 2 make-over: The GNU Autotools was created almost soly for the perpose of easier porting, albeit it only works in a Un*x environment. The only platforms that is then left out is Windoze and MacOS. However, an excellent Unix-like environment exist for Windoze, namely CygWin - but unfortunally, the GNU Autotools only work with GCC on that platform, not Micros**t Visual C/C++ (yet!). On MacOS I don't know. To me, this is not really a problem. I'd use autotools for Un*x and handwritten NMAKE Makefiles for Windoze, since the MSVC compilers are anyway so different from GCC and other Un*x compilers that you'd probably need that anyway. [...] On Un*x, you can use _any_ C/C++/Fortran(77,90,95)/RatFor compiler with the GNU Autotools. I is true that Autotools prefer g++ and g77 to any other compiler, but setting the environment variables CXX and FC, you can easily switch compiler, and all you need to do is run configure again - no need to change Makefiles and so on. Here's what I wrote to Fons once: The major problem, as I see it, is that one has to do a bit of tweaking to get Autotools to work with MSVC, since the Makefiles generated assumes that the compiler understands some specific command line options and flags [Common to UN*X compilers]. The most viable work-around, I believe, is to have a wrapper script like the one you have in build/win32/cc to translate GCC like flags and options to MSVC the same. I started a small project on the that some months ago, but got detoured due to some other work. I believe I made that point back then too: If we want to build BRAT with M$VC we have to make seperate makefiles, just like in the "good old" BRAT 1 days. Alternatively, someone with long-term experience in using M$VC (shudder) could provide a .dsw for BRAT 2. If anybody would like to continue my "wrapper" project, I'll be happy to provide my rough sketch. I think I mentioned the idea to the Autotools developers (and then again I may not have), but I can't remember what came off it. Debuggers - hmp! Who needs them? - No, just joking, though I think someone in the Collab once said something like (qouted from memory): You don't need a debugger! If you design you software well enough, and code it well enough, debuggers are a worthless waste of time. That may be to harsh, but still it has some truth in it. Finally, I've tried the M$VC debugger, and I was not impressed. Essentially it's too clumbersome for my taste. A good thing about the Integrated Development Environment (IDE) projects for Un*x out there, is that they're not trying to mimick the M$VC debugger down to every single quirk and bug. In fact, they're being clever and standing on the shoulders of giants like RMS. As for VMS - what is that? Something from the stoneages or something :-) A man was walking down broadway with his daugther in hand. He points to a building at says "There I used to work for Digital - we made VMS!" The kid looks puzzled and asks the her father "Dad, what's VMS?" "That was the great OS of it's time, and I used it!" answers har father. The kid looks even more puzzled, and finally ask her father "Dad, does that mean that companies made software, and made money off it? That information wasn't free?" with an obvious look of detest. "Ah, yes my daugther, back in those days we toiled!" Seriously Kris, VMS has been outdated for a great many years, look to the future. VMS was good at what it did, on the hardware back then. My only regret about all that, is that Digital didn't managed to promote their superiour chip technology to the desktop (or personal computer, or even PC) market. So now we stuck with these sh**ty i386 chips! And if you think Unix is ugly in design and Linux is the prime example of that, you are in a way right, and let me point you to a truely cool OS desgin - Hurd! Heck, in Hurd you can insert your own Kernel debugger if you like! Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm [1] http://cygwin.com/packages/ [2] http://www.gnu.org/software/libtool/manual.html#Tested%20platforms
This archive was generated by hypermail 2b30 : Mon Nov 19 2001 - 18:29:28 EST