Re: [Sablevm-developer] Merging CP 0.09 into svm-cp/staging

[Grzegorz B. P. <ga...@de...>]

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