Thread: [Sablevm-developer] Merging CP 0.09 into svm-cp/staging
Brought to you by:
egagnon
From: Grzegorz B. P. <ga...@de...> - 2004-05-04 06:11:11
|
Hi Etienne, would it be possible to merge latest GNU CP CVS into our staging (or at least vendor branch)? I'd like to see 1.1.4 soon, maybe this weekend even. GBP -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
From: Etienne G. <gag...@uq...> - 2004-05-04 06:48:08
|
Grzegorz B. Prokopski wrote: > would it be possible to merge latest GNU CP CVS into our > staging (or at least vendor branch)? Done. Ideally, I'd like to see the $(M4) and the -lrt problems solved before we release 1.1.4. I won't have time to solve them, so have fun doing it. :-) Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Grzegorz B. P. <ga...@de...> - 2004-05-04 07:12:08
|
On (04/05/04 02:42), Etienne Gagnon wrote: > Grzegorz B. Prokopski wrote: > >would it be possible to merge latest GNU CP CVS into our > >staging (or at least vendor branch)? > > Done. > > Ideally, I'd like to see the $(M4) and the -lrt problems solved before > we release 1.1.4. I won't have time to solve them, so have fun doing > it. :-) -lrt (and others of that kind) is on my todo list. I haven't looked at M4 yet but I am open for suggestions how it should look like. I have a few other small items for M4 ex. the last architecture that still bothers me: ARM :-) GBP -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
From: Etienne G. <gag...@uq...> - 2004-05-05 18:02:21
|
Grzegorz B. Prokopski wrote: > -lrt (and others of that kind) is on my todo list. I haven't looked at > M4 yet but I am open for suggestions how it should look like. I have > a few other small items for M4 ex. the last architecture that still > bothers me: ARM :-) To summarize: * I'd like configure to do something like: ## Pseudo-code! if (-lrt is required) ## This is a configure test that tries to ## compile a little C program witout -lrt LIBSVMINCLUDE = -lrt else LIBSVMINCLUDE = endif Then use @LIBSVMINCLUDE@ in Makefile.am. * I'd like configure to also do something like: # Pseudo-code if ($M4 is not defined) if (m4 is GNU m4) ## This should actually be a configure test ## that executes m4 and looks for GNU m4 specific ## behavior M4 = m4 else if (gm4 is GNU m4) M4 = gm4 endif endif Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Grzegorz B. P. <ga...@de...> - 2004-05-06 00:16:15
|
On (05/05/04 13:53), Etienne Gagnon wrote: > Grzegorz B. Prokopski wrote: > >-lrt (and others of that kind) is on my todo list. I haven't looked at > >M4 yet but I am open for suggestions how it should look like. I have > >a few other small items for M4 ex. the last architecture that still > >bothers me: ARM :-) > > To summarize: > > * I'd like configure to do something like: > > ## Pseudo-code! > if (-lrt is required) ## This is a configure test that tries to > ## compile a little C program witout -lrt Unless you or somebody else is able to provide a good explanation or a C program that fails or not, depending on the need for sablevm to use -lrt, I'd say that we have only one special case of OS which needs -lrt, which is Solaris. So we'll make NO -lrt the default and -lrt special case for Solaris. I googled a bit for "librt" and there's no clues as to what Solaris keeps in their librt that we need... Under linux it's some stuff we definitely don't need. I remember that we had similar issue with -lpthread which in turn was NOT tolerated by OS X and instead(?) David used -lc_r. So again I'd make -lpthread the default and OS X a special case with different libs. > * I'd like configure to also do something like: > > # Pseudo-code > if ($M4 is not defined) > if (m4 is GNU m4) ## This should actually be a configure test > ## that executes m4 and looks for GNU m4 specific > ## behavior > M4 = m4 > else if (gm4 is GNU m4) > M4 = gm4 > endif > endif I'd say that we try 1. $M4 (we just use it if set) 2. gm4 (we just use it if available, unless somebody tells me that there exist some other program called gm4 which is not GNU m4) 3. m4 (we fallback to this no matter what, as currently) We do NOT want to fail if m4 is not found or it is not gnu-compatible m4, because we neither want nor have m4 dependency at build time, that is unless you build from SVN or you've modified some files that other files are generated from. What we might do is to check whether the m4 we've choosen fails on "m4 -P ..." or not and generate a BIG warning at configure time. There will be additional @no_undefined@ needed for Cygwin (and MinGW one day) - it can be handled the same way. This is what I am going to implement. If somebody has a better idea (and backed with good clues as to how it should be implemented) please speak up. Cheers, GBP PS: Please see this message and the following thread for reference: http://thread.gmane.org/gmane.comp.java.vm.sablevm.devel/511 -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |