subject:"\[osg\-users\] 2.8\: XUL not completely found"


Hi Robert,

Paul Melis wrote:

Robert Osfield wrote:
  

I've tweaked the FindXUL.cmake to make the pkgconfig usage optional -
required as not all platforms have pkgconfig available.  The block now
looks like below segment.  The modified FindXUL.cmake is attached,
could you try this out?
  


Yep, seems to work fine.
  
A question: I think I saw you mention somewhere that XUL 1.9 is not 
supported, that 1.8 is the version to use. Is this correct?


I'm having some trouble getting 2.8 to compile on an FC10 system (after 
having to hack the CMake XUL module, as it uses different pkg-config 
names for the XUL packages). Specifically, 
src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h, 
which on the FC10 system, is located in a subdirectory widget/ of the 
XUL include directory and therefore can't be found using the current 
include directories set from the CMake module.


Looking further into this it seems that that header (nsIBaseWindow.h) is 
nowhere to be found in any of the 1.8 official distributions from Mozilla!
(e.g. 
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/)


So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9?

Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

Hi Paul,

I'm compiling against xulrunner 1.8.1.16:

pkg-config xulrunner-xpcom --modversion
1.8.1.16

Ubuntu repositories have both 1.8 and 1.9 available, but there are
under different names.  libxul gets you 1.8.x, while xulrunner gets
you 1.9.

Perhaps there is another component you need to install for 1.8.1 to
get everything you need to compile.

At your end could you see if you can the gecko plugin compiling
against 1.9.  Given what Callum wrote about the likihood of an easy
port I do wonder if it might not through up quite a few issues.  One
thing on our side is that I deliberately didn't patch gecko like
mozilla source normally did for UBrowser, this meant that some of the
UBrowser functionality couldn't be exposed by our gecko plugin, but
for us it might also mean that we are less exposed to changes between
1.8 and 1.9.

Robert.

On Fri, Feb 6, 2009 at 12:17 PM, Paul Melis p...@science.uva.nl wrote:
 Robert Osfield wrote:

 On Fri, Feb 6, 2009 at 11:38 AM, Paul Melis p...@science.uva.nl wrote:


 A question: I think I saw you mention somewhere that XUL 1.9 is not
 supported, that 1.8 is the version to use. Is this correct?


 Our gecko plugin is based on Ubrowser + XUL 1.8.x.  I exchange a
 number of emails with Callum Prentice, the author of Ubrowser,  about
 porting to to XUL 1.9 and he said that their are number of changes
 between the two version that include removal of functionality UBrowser
 relied upon, and the mozilla developer mailing lists were very
 unhelpful in helper guide others trying to use the API and the lack of
 docs meant that it would have been a lot of work to guess how to
 proceed with a port.

 Callum is now concentrating on Qt + WebKit integration that isn't yet
 released but should be some time in the spring.  I guess it might
 event be a part of Qt 4.5.  Callum has now moved on from looking at
 the gecko side as it was just too hard to get working well.

 I went for the gecko route purely because all the other solutions out
 there required modifying webkit sources and compiling it's oneself.
 There are at least  xulrunner 1.8 still available on some platforms
 off the shelf.  This won't be a long term thing though... 1.9 is
 replacing it...


 Hmm, I haven't looked at webkit in detail but heard mostly good things about
 it, too bad it's not usable at this point yet.



 I'm having some trouble getting 2.8 to compile on an FC10 system (after
 having to hack the CMake XUL module, as it uses different pkg-config
 names
 for the XUL packages). Specifically,
 src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h,
 which on the FC10 system, is located in a subdirectory widget/ of the XUL
 include directory and therefore can't be found using the current include
 directories set from the CMake module.


 The gecko/CMakeLists.txt does have an entry for the widget subdirectory:

${XUL_INCLUDE_DIR}/widget


 pkg-config libxul --cflags on this FC10 system reports:
 -fshort-wchar -I/usr/include/xulrunner-sdk-1.9/stable -I/usr/include/nspr4

 and so XUL_INCLUDE_DIR gets set to /usr/include/xulrunner-sdk-1.9/stable by
 CMake.
 However, the directories widget/ and such are not subdirecories of the
 stable/ dir but are siblings!

 It seems that the files in stable/ are some sort of backwards-compatible 1.8
 API, that are not present in the official 1.9 SDK.

 Looking further into this it seems that that header (nsIBaseWindow.h) is
 nowhere to be found in any of the 1.8 official distributions from
 Mozilla!
 (e.g.

 http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/)




 Forgot to mention that the header IS included in 1.9, but you probably
 guessed

 Ar building on shifting sand


 We perhaps should check wether there have been any successful builds of the
 gecko plugin against xulrunner 1.8.
 I have a hunch everybody is using 1.9 these days :)

 So could it be that the gecko plugin does not needs xulrunner 1.8, but
 1.9?


 We could try to port to 1.9, but... it could well take a while.


 I think that we already use 1.9 everywhere, simply because the plugin
 shouldn't compile against 1.8 without errors.
 On an old FC4 system I *do* see the nsIBaseWindow.h header, but there it is
 part of mozilla-1.7.13. So it's quite a big jungle where those headers the
 gecko plugin uses comes from :-/

 Did you not say that you got things working yesterday?  What haw
 changed since then?


 That I'm now compiling on a different system (FC10 instead of Gentoo).

 I'm not very motivated to keep track and handle all different XUL
 installations out there. I guess on the long run porting to 1.9 (or taking
 another look at webkit) might be the best way forward.

 Paul

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list

Re: [osg-users] 2.8: XUL not completely found


Robert Osfield wrote:

Hi Paul,

I'm compiling against xulrunner 1.8.1.16:

pkg-config xulrunner-xpcom --modversion
1.8.1.16

Ubuntu repositories have both 1.8 and 1.9 available, but there are
under different names.  libxul gets you 1.8.x, while xulrunner gets
you 1.9.

Perhaps there is another component you need to install for 1.8.1 to
get everything you need to compile.

At your end could you see if you can the gecko plugin compiling
against 1.9. 
The nsBuildID.h file (included by llembeddedbrowser.cpp) is not in 1.9 
(but is in 1.8), and I see some API incompabilities leading to errors, 
so compiling against pure 1.9 won't work.
I really wonder where the stuff that isn't in 1.8 but that IS used by 
the gecko plugin comes from (like nsIBaseWindow.h). Can you check on 
your end?


Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

Hi Paul,
My nsIBaseWindow.h is in /usr/include/xulrunner/widget/nsIBaseWindow.h

   /usr/include/xulrunner$ find . -name  nsIBaseWindow.h
  ./widget/nsIBaseWindow.h

I have attached the file.  Doing a grep for nsIBaseWindow there are
couple more instances that reference it:

grep nsIBaseWindow */*
docshell/nsCDocShell.h:#ifndef __gen_nsIBaseWindow_h__
docshell/nsCDocShell.h:#include nsIBaseWindow.h
webbrwsr/nsCWebBrowser.h:#ifndef __gen_nsIBaseWindow_h__
webbrwsr/nsCWebBrowser.h:#include nsIBaseWindow.h


Given that we are unlikely to be able to port to 1.9.x for 2.8 we'll
need to change the FindXUL.cmake to only match 1.8.x.  Any thoughts on
how to do this?

Also what version of libxul/xulrunner do you have available? Is it
just 1.9 on Fedora10, or can you get 1.8 as well.  When you got the
gecko plugin working the other day what platform was this, and which
xulrunner version was it?

Robert.


Robert.

On Fri, Feb 6, 2009 at 1:02 PM, Paul Melis p...@science.uva.nl wrote:
 Robert Osfield wrote:

 Hi Paul,

 I'm compiling against xulrunner 1.8.1.16:

 pkg-config xulrunner-xpcom --modversion
 1.8.1.16

 Ubuntu repositories have both 1.8 and 1.9 available, but there are
 under different names.  libxul gets you 1.8.x, while xulrunner gets
 you 1.9.

 Perhaps there is another component you need to install for 1.8.1 to
 get everything you need to compile.

 At your end could you see if you can the gecko plugin compiling
 against 1.9.

 The nsBuildID.h file (included by llembeddedbrowser.cpp) is not in 1.9 (but
 is in 1.8), and I see some API incompabilities leading to errors, so
 compiling against pure 1.9 won't work.
 I really wonder where the stuff that isn't in 1.8 but that IS used by the
 gecko plugin comes from (like nsIBaseWindow.h). Can you check on your end?

 Paul
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

/*
 * DO NOT EDIT.  THIS FILE IS GENERATED FROM nsIBaseWindow.idl
 */

#ifndef __gen_nsIBaseWindow_h__
#define __gen_nsIBaseWindow_h__


#ifndef __gen_nsISupports_h__
#include nsISupports.h
#endif

#ifndef __gen_nsrootidl_h__
#include nsrootidl.h
#endif

/* For IDL files that don't want to include root IDL files. */
#ifndef NS_NO_VTABLE
#define NS_NO_VTABLE
#endif
class nsIWidget;
typedef void * nativeWindow;


/* starting interface:nsIBaseWindow */
#define NS_IBASEWINDOW_IID_STR 046bc8a0-8015-11d3-af70-00a024ffc08c

#define NS_IBASEWINDOW_IID \
  {0x046bc8a0, 0x8015, 0x11d3, \
{ 0xaf, 0x70, 0x00, 0xa0, 0x24, 0xff, 0xc0, 0x8c }}

/**
 * The nsIBaseWindow describes a generic window and basic operations that 
 * can be performed on it.  This is not to be a complete windowing interface
 * but rather a common set that nearly all windowed objects support.
 */
class NS_NO_VTABLE nsIBaseWindow : public nsISupports {
 public: 

  NS_DEFINE_STATIC_IID_ACCESSOR(NS_IBASEWINDOW_IID)

  /* [noscript] void initWindow (in nativeWindow parentNativeWindow, in nsIWidget parentWidget, in long x, in long y, in long cx, in long cy); */
  NS_IMETHOD InitWindow(nativeWindow parentNativeWindow, nsIWidget * parentWidget, PRInt32 x, PRInt32 y, PRInt32 cx, PRInt32 cy) = 0;

  /* void create (); */
  NS_IMETHOD Create(void) = 0;

  /* void destroy (); */
  NS_IMETHOD Destroy(void) = 0;

  /* void setPosition (in long x, in long y); */
  NS_IMETHOD SetPosition(PRInt32 x, PRInt32 y) = 0;

  /* void getPosition (out long x, out long y); */
  NS_IMETHOD GetPosition(PRInt32 *x, PRInt32 *y) = 0;

  /* void setSize (in long cx, in long cy, in boolean fRepaint); */
  NS_IMETHOD SetSize(PRInt32 cx, PRInt32 cy, PRBool fRepaint) = 0;

  /* void getSize (out long cx, out long cy); */
  NS_IMETHOD GetSize(PRInt32 *cx, PRInt32 *cy) = 0;

  /* void setPositionAndSize (in long x, in long y, in long cx, in long cy, in boolean fRepaint); */
  NS_IMETHOD SetPositionAndSize(PRInt32 x, PRInt32 y, PRInt32 cx, PRInt32 cy, PRBool fRepaint) = 0;

  /* void getPositionAndSize (out long x, out long y, out long cx, out long cy); */
  NS_IMETHOD GetPositionAndSize(PRInt32 *x, PRInt32 *y, PRInt32 *cx, PRInt32 *cy) = 0;

  /** 
	 * Tell the window to repaint itself
	 * @param aForce - if true, repaint immediately
	 * if false, the window may defer repainting as it sees fit.
	 */
  /* void repaint (in boolean force); */
  NS_IMETHOD Repaint(PRBool force) = 0;

  /* [noscript] attribute nsIWidget parentWidget; */
  NS_IMETHOD GetParentWidget(nsIWidget * *aParentWidget) = 0;
  NS_IMETHOD SetParentWidget(nsIWidget * aParentWidget) = 0;

  /* attribute nativeWindow parentNativeWindow; */
  NS_IMETHOD GetParentNativeWindow(nativeWindow *aParentNativeWindow) = 0;
  NS_IMETHOD SetParentNativeWindow(nativeWindow aParentNativeWindow) = 0;

  /* attribute boolean visibility; */
  NS_IMETHOD GetVisibility(PRBool *aVisibility) = 0;
  NS_IMETHOD SetVisibility(PRBool aVisibility) = 0;

  /* attribute

Re: [osg-users] 2.8: XUL not completely found

Robert Osfield wrote:

My nsIBaseWindow.h is in /usr/include/xulrunner/widget/nsIBaseWindow.h

/usr/include/xulrunner$ find . -name nsIBaseWindow.h
./widget/nsIBaseWindow.h

Just found some enlightenment
(http://groups.google.com/group/mozilla.dev.embedding/browse_thread/thread/23257b1e3315a11f/c136034a7e04aeef):

Andrew Gough wrote:
Is it supposed to be theoretically possible to embed XulRunner 1.8.1.3
at all?

I am trying (once again) to make this work, so I downloaded the SDK
runtime for xulrunner-1.8.1.3, and attempted to compile against it.

The SDK only contains *frozen* interfaces and headers. It is currently not
possible to usefully embed gecko using only frozen interfaces: you will
have

to use internal interfaces such as nsIBaseWindow as well.

So if the question is Is it possible to embed XULRunner 1.8.1.3 by
compiling against the SDK? the answer is no. If the question is Is it
possible to embed XULRunner 1.8.1.3? the answer is yes. But you'll need to
obtain the nonfrozen headers/interfaces from the source tarball.

So that header is part of an internal API that might change and explains
why your 1.8 installation contains headers that are not in the SDK.

And explains why the gecko plugin builds there as well.

I have attached the file. Doing a grep for nsIBaseWindow there are
couple more instances that reference it:

grep nsIBaseWindow */*
docshell/nsCDocShell.h:#ifndef __gen_nsIBaseWindow_h__
docshell/nsCDocShell.h:#include nsIBaseWindow.h
webbrwsr/nsCWebBrowser.h:#ifndef __gen_nsIBaseWindow_h__
webbrwsr/nsCWebBrowser.h:#include nsIBaseWindow.h

Given that we are unlikely to be able to port to 1.9.x for 2.8 we'll
need to change the FindXUL.cmake to only match 1.8.x. Any thoughts on
how to do this?

pkg-config supports version requirements, which the CMake pkg-config
calls support as well.

From /usr/share/cmake/Modules/FindPkgConfig.cmake:

# pkg_check_modules (GLIB2 glib-2.0=2.10)
# requires at least version 2.10 of glib2 and defines e.g.
# GLIB2_VERSION=2.10.3

I would expect = to work as well, instead of =

Also what version of libxul/xulrunner do you have available? Is it
just 1.9 on Fedora10, or can you get 1.8 as well.

Installed:
xulrunner.i3861.9.0.6-1.fc10
installed
xulrunner-devel.i386 1.9.0.6-1.fc10
installed

Available:
xulrunner-devel-unstable.i386 1.9.0.6-1.fc10 updates
xulrunner-python.i386 1.9.0.6-1.fc10 updates
xulrunner-python-devel.i3861.9.0.6-1.fc10 updates

So only 1.9.0.6 on FC10.

When you got the gecko plugin working the other day what
platform was this, and which xulrunner version was it?

That was my home machine, which runs gentoo, where xulrunner 1.8.1.19 and
1.9.0.5 are available and both are installed.
CMake detected 1.8 there, as xulrunner-1.9 uses libxul and mozilla- for its
pkg-config files. 1.8 uses xulrunner.
So you can use the latter one in FindXUL.cmake.

Paul

Robert.

On Fri, Feb 6, 2009 at 1:02 PM, Paul Melis p...@science.uva.nl wrote:

Robert Osfield wrote:

Hi Paul,

I'm compiling against xulrunner 1.8.1.16:

pkg-config xulrunner-xpcom --modversion
1.8.1.16

Ubuntu repositories have both 1.8 and 1.9 available, but there are
under different names. libxul gets you 1.8.x, while xulrunner gets
you 1.9.

Perhaps there is another component you need to install for 1.8.1 to
get everything you need to compile.

At your end could you see if you can the gecko plugin compiling
against 1.9.

The nsBuildID.h file (included by llembeddedbrowser.cpp) is not in 1.9 (but
is in 1.8), and I see some API incompabilities leading to errors, so
compiling against pure 1.9 won't work.
I really wonder where the stuff that isn't in 1.8 but that IS used by the
gecko plugin comes from (like nsIBaseWindow.h). Can you check on your end?

Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

Hi Paul,

Good detective work.  So we need to do two things - make sure we don't
pick up on 1.9, and make sure that nsIBaseWindow.h is available.  I
have just tried out the following changes to FindXUL.cmake:

IF(PKG_CONFIG_FOUND)

INCLUDE(FindPkgConfig)

pkg_check_modules(XULRUNNER_XPCOM xulrunner-xpcom=1.8.9)
pkg_check_modules(XULRUNNER_JS xulrunner-js)
pkg_check_modules(XULRUNNER_NSPR xulrunner-nspr)
pkg_check_modules(XULRUNNER_NSS xulrunner-nss)

ENDIF(PKG_CONFIG_FOUND)

# Added check to make sure that nsIBaseWindow.h is available, as it's
not a standard part the of 1.8.x SDK
FIND_PATH(NSIBASEWINDOW_INCLUDE_DIR widget/nsIBaseWindow.h
PATHS ${XULRUNNER_XPCOM_INCLUDE_DIRS}
$ENV{OSG_DIR}/include/xulrunner
$ENV{OSG_DIR}/include

Could you please try this out on your system, hopefully it'll not
register XUL as being found on your system.  While not perfect, it
will at least mean you won't have a broken build.

Robert.


FindXUL.cmake
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found


Robert Osfield wrote:

Hi Paul,

Good detective work.  So we need to do two things - make sure we don't
pick up on 1.9, and make sure that nsIBaseWindow.h is available.  I
have just tried out the following changes to FindXUL.cmake:

IF(PKG_CONFIG_FOUND)

INCLUDE(FindPkgConfig)

pkg_check_modules(XULRUNNER_XPCOM xulrunner-xpcom=1.8.9)
pkg_check_modules(XULRUNNER_JS xulrunner-js)
pkg_check_modules(XULRUNNER_NSPR xulrunner-nspr)
pkg_check_modules(XULRUNNER_NSS xulrunner-nss)

ENDIF(PKG_CONFIG_FOUND)

# Added check to make sure that nsIBaseWindow.h is available, as it's
not a standard part the of 1.8.x SDK
FIND_PATH(NSIBASEWINDOW_INCLUDE_DIR widget/nsIBaseWindow.h
PATHS ${XULRUNNER_XPCOM_INCLUDE_DIRS}
$ENV{OSG_DIR}/include/xulrunner
$ENV{OSG_DIR}/include

Could you please try this out on your system, hopefully it'll not
register XUL as being found on your system.  While not perfect, it
will at least mean you won't have a broken build.
  
On Gentoo this (still) correctly detects 1.8 and the gecko plugin gets 
built.
On FC10 this correctly fails to detect 1.9 and the gecko plugin is NOT 
built.


Looks good!
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

On Fri, Feb 6, 2009 at 3:18 PM, Paul Melis p...@science.uva.nl wrote:
 On Gentoo this (still) correctly detects 1.8 and the gecko plugin gets
 built.
 On FC10 this correctly fails to detect 1.9 and the gecko plugin is NOT
 built.

That's a relief, these changes are now checked into OSG-2.8 and svn/trunk.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

Hi Paul,

On Fri, Feb 6, 2009 at 11:38 AM, Paul Melis p...@science.uva.nl wrote:
 A question: I think I saw you mention somewhere that XUL 1.9 is not
 supported, that 1.8 is the version to use. Is this correct?

Our gecko plugin is based on Ubrowser + XUL 1.8.x.  I exchange a
number of emails with Callum Prentice, the author of Ubrowser,  about
porting to to XUL 1.9 and he said that their are number of changes
between the two version that include removal of functionality UBrowser
relied upon, and the mozilla developer mailing lists were very
unhelpful in helper guide others trying to use the API and the lack of
docs meant that it would have been a lot of work to guess how to
proceed with a port.

Callum is now concentrating on Qt + WebKit integration that isn't yet
released but should be some time in the spring.  I guess it might
event be a part of Qt 4.5.  Callum has now moved on from looking at
the gecko side as it was just too hard to get working well.

I went for the gecko route purely because all the other solutions out
there required modifying webkit sources and compiling it's oneself.
There are at least  xulrunner 1.8 still available on some platforms
off the shelf.  This won't be a long term thing though... 1.9 is
replacing it...

 I'm having some trouble getting 2.8 to compile on an FC10 system (after
 having to hack the CMake XUL module, as it uses different pkg-config names
 for the XUL packages). Specifically,
 src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h,
 which on the FC10 system, is located in a subdirectory widget/ of the XUL
 include directory and therefore can't be found using the current include
 directories set from the CMake module.

The gecko/CMakeLists.txt does have an entry for the widget subdirectory:

${XUL_INCLUDE_DIR}/widget

 Looking further into this it seems that that header (nsIBaseWindow.h) is
 nowhere to be found in any of the 1.8 official distributions from Mozilla!
 (e.g.
 http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/)

Ar building on shifting sand

 So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9?

We could try to port to 1.9, but... it could well take a while.

Did you not say that you got things working yesterday?  What haw
changed since then?

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found


Robert Osfield wrote:

On Fri, Feb 6, 2009 at 11:38 AM, Paul Melis p...@science.uva.nl wrote:
  

A question: I think I saw you mention somewhere that XUL 1.9 is not
supported, that 1.8 is the version to use. Is this correct?



Our gecko plugin is based on Ubrowser + XUL 1.8.x.  I exchange a
number of emails with Callum Prentice, the author of Ubrowser,  about
porting to to XUL 1.9 and he said that their are number of changes
between the two version that include removal of functionality UBrowser
relied upon, and the mozilla developer mailing lists were very
unhelpful in helper guide others trying to use the API and the lack of
docs meant that it would have been a lot of work to guess how to
proceed with a port.

Callum is now concentrating on Qt + WebKit integration that isn't yet
released but should be some time in the spring.  I guess it might
event be a part of Qt 4.5.  Callum has now moved on from looking at
the gecko side as it was just too hard to get working well.

I went for the gecko route purely because all the other solutions out
there required modifying webkit sources and compiling it's oneself.
There are at least  xulrunner 1.8 still available on some platforms
off the shelf.  This won't be a long term thing though... 1.9 is
replacing it...
  
Hmm, I haven't looked at webkit in detail but heard mostly good things 
about it, too bad it's not usable at this point yet.
  

I'm having some trouble getting 2.8 to compile on an FC10 system (after
having to hack the CMake XUL module, as it uses different pkg-config names
for the XUL packages). Specifically,
src/osgPlugins/gecko/llembeddedbrowserwindow.h includes nsIBaseWindow.h,
which on the FC10 system, is located in a subdirectory widget/ of the XUL
include directory and therefore can't be found using the current include
directories set from the CMake module.



The gecko/CMakeLists.txt does have an entry for the widget subdirectory:

${XUL_INCLUDE_DIR}/widget
  

pkg-config libxul --cflags on this FC10 system reports:
-fshort-wchar -I/usr/include/xulrunner-sdk-1.9/stable -I/usr/include/nspr4

and so XUL_INCLUDE_DIR gets set to /usr/include/xulrunner-sdk-1.9/stable 
by CMake.
However, the directories widget/ and such are not subdirecories of the 
stable/ dir but are siblings!


It seems that the files in stable/ are some sort of backwards-compatible 
1.8 API, that are not present in the official 1.9 SDK.

Looking further into this it seems that that header (nsIBaseWindow.h) is
nowhere to be found in any of the 1.8 official distributions from Mozilla!
(e.g.
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/)



  
Forgot to mention that the header IS included in 1.9, but you probably 
guessed

Ar building on shifting sand
  
We perhaps should check wether there have been any successful builds of 
the gecko plugin against xulrunner 1.8.

I have a hunch everybody is using 1.9 these days :)

So could it be that the gecko plugin does not needs xulrunner 1.8, but 1.9?



We could try to port to 1.9, but... it could well take a while.
  
I think that we already use 1.9 everywhere, simply because the plugin 
shouldn't compile against 1.8 without errors.
On an old FC4 system I *do* see the nsIBaseWindow.h header, but there it 
is part of mozilla-1.7.13. So it's quite a big jungle where those 
headers the gecko plugin uses comes from :-/

Did you not say that you got things working yesterday?  What haw
changed since then?
  

That I'm now compiling on a different system (FC10 instead of Gentoo).

I'm not very motivated to keep track and handle all different XUL 
installations out there. I guess on the long run porting to 1.9 (or 
taking another look at webkit) might be the best way forward.


Paul

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

2009-02-05 Thread Robert Osfield

Hi Paul,

I've just reviewed your modified FindXUL.cmake and found it to be
identical to the one in OSG-2.8/svn/trunk.  Same problem as the mods
for DCMTK...

Robert.

On Wed, Feb 4, 2009 at 8:13 PM, Paul Melis
osg-us...@assumetheposition.nl wrote:
 Hi Robert,

 Here's an updated FindXUL.cmake that works for me. It uses pkg-config to
 discover some extra paths.
 Now osgbrowser google.com works for me!

 Two remarks:
 - It doesn't do any version checks, although the pkg-config CMake macros
 are capable of this (but I don't know if there are any version reqs)
 - The paths discovered with pkg-config are put in the front of the
 existing lists

 Paul

 Robert Osfield wrote:
 HI Paul,

 There is pkg-config support in CMake, but I don't know how flexible it is.

 BTW, what happens on your Gentoo system?  Does the half found XUL
 cause a build failure or does the gecko plugin simply not compile?

 Robert.

 On Wed, Feb 4, 2009 at 6:22 PM, Paul Melis
 osg-us...@assumetheposition.nl wrote:

 I just noticed (on a Gentoo system) that not all of the parts of XUL are
 found by CMake.
 Some of the include directories and libraries are not among the ones in
 FindXUL.cmake.
 There does seem to be pkg-config support for it though:

 # nsEmbedAPI.h
 pkg-config libxul-embedding --cflags
 # jsapi.h
 pkg-config xulrunner-js --cflags
 # prtypes.h
 pkg-config xulrunner-nspr --cflags

 Does CMake have support for parsing the output of pkg-config?

 Paul
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




 # Locate gdal
 # This module defines
 # XUL_LIBRARIES
 # XUL_FOUND, if false, do not try to link to gdal
 # XUL_INCLUDE_DIR, where to find the headers
 #
 # $XUL_DIR is an environment variable that would
 # correspond to the ./configure --prefix=$XUL_DIR
 #
 # Created by Robert Osfield.

 FIND_PATH(XUL_INCLUDE_DIR nsEmbedAPI.h
$ENV{OSG_DIR}/include/xulrunner
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/xulrunner
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/xulrunner
$ENV{OSGDIR}/include
$ENV{OSGDIR}/xulrunner
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/xulrunner
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/xulrunner
/usr/local/include
/usr/include/xulrunner
/usr/include
/sw/include/xulrunner # Fink
/sw/include # Fink
/opt/local/include/xulrunner # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/xulrunner # Blastwave
/opt/csw/include # Blastwave
/opt/include/xulrunner
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
 Manager\\Environment;OSG_ROOT]/include/xulrunner
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
 Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/xulrunner
/usr/freeware/include
 )

 FIND_PATH(NSPR_INCLUDE_DIR prtypes.h
$ENV{OSG_DIR}/include/nspr
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/nspr
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/nspr
$ENV{OSGDIR}/include
$ENV{OSGDIR}/nspr
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/nspr
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/nspr
/usr/local/include
/usr/include/nspr
/usr/include
/sw/include/nspr # Fink
/sw/include # Fink
/opt/local/include/nspr # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/nspr # Blastwave
/opt/csw/include # Blastwave
/opt/include/nspr
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
 Manager\\Environment;OSG_ROOT]/include/nspr
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
 Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/nspr
/usr/freeware/include
 )

 FIND_PATH(MOZJS_INCLUDE_DIR jsapi.h
$ENV{OSG_DIR}/include/mozjs
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/mozjs
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/mozjs
$ENV{OSGDIR}/include
$ENV{OSGDIR}/mozjs
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/mozjs
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/mozjs
/usr/local/include
/usr/include/mozjs
/usr/include
/sw/include/mozjs # Fink
/sw/include # Fink
/opt/local/include/mozjs # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/mozjs # Blastwave
/opt/csw/include # Blastwave
/opt/include/mozjs
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ 
 Manager\\Environment;OSG_ROOT]/include/mozjs
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\

Re: [osg-users] 2.8: XUL not completely found


Robert Osfield wrote:

I've just reviewed your modified FindXUL.cmake and found it to be
identical to the one in OSG-2.8/svn/trunk.  Same problem as the mods
for DCMTK...
  
I have no idea what happened last night, but I guess I wasn't paying 
attention :)


Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

Robert Osfield wrote:
 Hi Paul,

 I've just reviewed your modified FindXUL.cmake and found it to be
 identical to the one in OSG-2.8/svn/trunk.  Same problem as the mods
 for DCMTK...
   
I must have sent you the versions from trunk, not the 2.8 branch.
Here are the correct files.

Paul
# - find DCMTK libraries
#

#  DCMTK_INCLUDE_DIRS  - Directories to include to use DCMTK
#  DCMTK_LIBRARIES - Files to link against to use DCMTK
#  DCMTK_FOUND - If false, don't try to use DCMTK
#  DCMTK_DIR   - (optional) Source directory for DCMTK
#
# DCMTK_DIR can be used to make it simpler to find the various include
# directories and compiled libraries if you've just compiled it in the
# source tree. Just set it to the root of the tree where you extracted
# the source.
#
# Written for VXL by Amitha Perera.
# Modified by Robert Osfied to enable support for install placements of DCMTK 
3.5.4 versions onwards

FIND_PATH( DCMTK_ROOT_INCLUDE_DIR dcmtk/config/osconfig.h
${DCMTK_DIR}/config/include
${DCMTK_DIR}/include
/usr/local/include/
/usr/include/
/usr/local/dicom/include/
)

FIND_PATH( DCMTK_config_INCLUDE_DIR osconfig.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/config
${DCMTK_DIR}/config/include
${DCMTK_DIR}/include
/usr/local/include/dcmtk/config
/usr/include/dcmtk/config
/usr/local/dicom/include/dcmtk/config
)

FIND_PATH( DCMTK_ofstd_INCLUDE_DIR ofstdinc.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/ofstd
${DCMTK_DIR}/ofstd/include
${DCMTK_DIR}/include/ofstd
/usr/local/include/dcmtk/ofstd
/usr/include/dcmtk/ofstd
/usr/local/dicom/include/dcmtk/ofstd
)

FIND_LIBRARY( DCMTK_ofstd_LIBRARY ofstd
${DCMTK_DIR}/ofstd/libsrc
${DCMTK_DIR}/ofstd/libsrc/Release
${DCMTK_DIR}/ofstd/libsrc/Debug
${DCMTK_DIR}/ofstd/Release
${DCMTK_DIR}/ofstd/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


FIND_PATH( DCMTK_dcmdata_INCLUDE_DIR dctypes.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/dcmdata
${DCMTK_DIR}/dcmdata/include
${DCMTK_DIR}/include/dcmdata
/usr/local/include/dcmtk/dcmdata
/usr/include/dcmtk/dcmdata
/usr/local/dicom/include/dcmtk/dcmdata
)

FIND_LIBRARY( DCMTK_dcmdata_LIBRARY dcmdata
${DCMTK_DIR}/dcmdata/libsrc
${DCMTK_DIR}/dcmdata/libsrc/Release
${DCMTK_DIR}/dcmdata/libsrc/Debug
${DCMTK_DIR}/dcmdata/Release
${DCMTK_DIR}/dcmdata/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


FIND_PATH( DCMTK_dcmimgle_INCLUDE_DIR dcmimage.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/dcmimgle
${DCMTK_DIR}/dcmimgle/include
${DCMTK_DIR}/include/dcmimgle
/usr/local/include/dcmtk/dcmimgle
/usr/include/dcmtk/dcmimgle
/usr/local/dicom/include/dcmtk/dcmimgle
)

FIND_LIBRARY( DCMTK_dcmimgle_LIBRARY dcmimgle
${DCMTK_DIR}/dcmimgle/libsrc
${DCMTK_DIR}/dcmimgle/libsrc/Release
${DCMTK_DIR}/dcmimgle/libsrc/Debug
${DCMTK_DIR}/dcmimgle/Release
${DCMTK_DIR}/dcmimgle/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)

FIND_LIBRARY(DCMTK_imagedb_LIBRARY imagedb
${DCMTK_DIR}/imagectn/libsrc/Release
${DCMTK_DIR}/imagectn/libsrc/
${DCMTK_DIR}/imagectn/libsrc/Debug
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)

FIND_LIBRARY(DCMTK_dcmnet_LIBRARY dcmnet
${DCMTK_DIR}/dcmnet/libsrc/Release
${DCMTK_DIR}/dcmnet/libsrc/Debug
${DCMTK_DIR}/dcmnet/libsrc/
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


IF( DCMTK_config_INCLUDE_DIR
AND DCMTK_ofstd_INCLUDE_DIR
AND DCMTK_ofstd_LIBRARY
AND DCMTK_dcmdata_INCLUDE_DIR
AND DCMTK_dcmdata_LIBRARY
AND DCMTK_dcmimgle_INCLUDE_DIR
AND DCMTK_dcmimgle_LIBRARY )

  SET( DCMTK_FOUND YES )
  SET( DCMTK_INCLUDE_DIRS
${DCMTK_config_INCLUDE_DIR}
${DCMTK_ofstd_INCLUDE_DIR}
${DCMTK_dcmdata_INCLUDE_DIR}
${DCMTK_dcmimgle_INCLUDE_DIR}
  )

  SET( DCMTK_LIBRARIES
${DCMTK_dcmimgle_LIBRARY}
${DCMTK_dcmdata_LIBRARY}
${DCMTK_ofstd_LIBRARY}
${DCMTK_config_LIBRARY}
  )

  IF(DCMTK_imagedb_LIBRARY)
   SET( DCMTK_LIBRARIES
   ${DCMTK_LIBRARIES}
   ${DCMTK_imagedb_LIBRARY}
   )
  ENDIF(DCMTK_imagedb_LIBRARY)

  IF(DCMTK_dcmnet_LIBRARY)
   SET( DCMTK_LIBRARIES
   ${DCMTK_LIBRARIES}
   ${DCMTK_dcmnet_LIBRARY}
   )
  ENDIF(DCMTK_dcmnet_LIBRARY)

  IF( WIN32 )
SET( DCMTK_LIBRARIES ${DCMTK_LIBRARIES} netapi32 )
  ENDIF( WIN32 )

ENDIF( DCMTK_config_INCLUDE_DIR
AND DCMTK_ofstd_INCLUDE_DIR
AND DCMTK_ofstd_LIBRARY
AND DCMTK_dcmdata_INCLUDE_DIR
AND DCMTK_dcmdata_LIBRARY
AND DCMTK_dcmimgle_INCLUDE_DIR
AND DCMTK_dcmimgle_LIBRARY )

IF( NOT DCMTK_FOUND )
  SET( DCMTK_DIR  CACHE PATH Root of DCMTK source tree (optional). )
  MARK_AS_ADVANCED( DCMTK_DIR )
ENDIF( NOT DCMTK_FOUND )
# Locate XUL
# This module

Re: [osg-users] 2.8: XUL not completely found

Paul Melis wrote:
 Robert Osfield wrote:
   
 Hi Paul,

 I've just reviewed your modified FindXUL.cmake and found it to be
 identical to the one in OSG-2.8/svn/trunk.  Same problem as the mods
 for DCMTK...
   
 
 I must have sent you the versions from trunk, not the 2.8 branch.
 Here are the correct files.
   
Dang, my thunderbird (on a fairly fresh system) wasn't updated to not
send attachements inline. Here's the two files again...

Paul
# - find DCMTK libraries
#

#  DCMTK_INCLUDE_DIRS  - Directories to include to use DCMTK
#  DCMTK_LIBRARIES - Files to link against to use DCMTK
#  DCMTK_FOUND - If false, don't try to use DCMTK
#  DCMTK_DIR   - (optional) Source directory for DCMTK
#
# DCMTK_DIR can be used to make it simpler to find the various include
# directories and compiled libraries if you've just compiled it in the
# source tree. Just set it to the root of the tree where you extracted
# the source.
#
# Written for VXL by Amitha Perera.
# Modified by Robert Osfied to enable support for install placements of DCMTK 
3.5.4 versions onwards

FIND_PATH( DCMTK_ROOT_INCLUDE_DIR dcmtk/config/osconfig.h
${DCMTK_DIR}/config/include
${DCMTK_DIR}/include
/usr/local/include/
/usr/include/
/usr/local/dicom/include/
)

FIND_PATH( DCMTK_config_INCLUDE_DIR osconfig.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/config
${DCMTK_DIR}/config/include
${DCMTK_DIR}/include
/usr/local/include/dcmtk/config
/usr/include/dcmtk/config
/usr/local/dicom/include/dcmtk/config
)

FIND_PATH( DCMTK_ofstd_INCLUDE_DIR ofstdinc.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/ofstd
${DCMTK_DIR}/ofstd/include
${DCMTK_DIR}/include/ofstd
/usr/local/include/dcmtk/ofstd
/usr/include/dcmtk/ofstd
/usr/local/dicom/include/dcmtk/ofstd
)

FIND_LIBRARY( DCMTK_ofstd_LIBRARY ofstd
${DCMTK_DIR}/ofstd/libsrc
${DCMTK_DIR}/ofstd/libsrc/Release
${DCMTK_DIR}/ofstd/libsrc/Debug
${DCMTK_DIR}/ofstd/Release
${DCMTK_DIR}/ofstd/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


FIND_PATH( DCMTK_dcmdata_INCLUDE_DIR dctypes.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/dcmdata
${DCMTK_DIR}/dcmdata/include
${DCMTK_DIR}/include/dcmdata
/usr/local/include/dcmtk/dcmdata
/usr/include/dcmtk/dcmdata
/usr/local/dicom/include/dcmtk/dcmdata
)

FIND_LIBRARY( DCMTK_dcmdata_LIBRARY dcmdata
${DCMTK_DIR}/dcmdata/libsrc
${DCMTK_DIR}/dcmdata/libsrc/Release
${DCMTK_DIR}/dcmdata/libsrc/Debug
${DCMTK_DIR}/dcmdata/Release
${DCMTK_DIR}/dcmdata/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


FIND_PATH( DCMTK_dcmimgle_INCLUDE_DIR dcmimage.h
${DCMTK_ROOT_INCLUDE_DIR}/dcmtk/dcmimgle
${DCMTK_DIR}/dcmimgle/include
${DCMTK_DIR}/include/dcmimgle
/usr/local/include/dcmtk/dcmimgle
/usr/include/dcmtk/dcmimgle
/usr/local/dicom/include/dcmtk/dcmimgle
)

FIND_LIBRARY( DCMTK_dcmimgle_LIBRARY dcmimgle
${DCMTK_DIR}/dcmimgle/libsrc
${DCMTK_DIR}/dcmimgle/libsrc/Release
${DCMTK_DIR}/dcmimgle/libsrc/Debug
${DCMTK_DIR}/dcmimgle/Release
${DCMTK_DIR}/dcmimgle/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)

FIND_LIBRARY(DCMTK_imagedb_LIBRARY imagedb
${DCMTK_DIR}/imagectn/libsrc/Release
${DCMTK_DIR}/imagectn/libsrc/
${DCMTK_DIR}/imagectn/libsrc/Debug
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)

FIND_LIBRARY(DCMTK_dcmnet_LIBRARY dcmnet
${DCMTK_DIR}/dcmnet/libsrc/Release
${DCMTK_DIR}/dcmnet/libsrc/Debug
${DCMTK_DIR}/dcmnet/libsrc/
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)


IF( DCMTK_config_INCLUDE_DIR
AND DCMTK_ofstd_INCLUDE_DIR
AND DCMTK_ofstd_LIBRARY
AND DCMTK_dcmdata_INCLUDE_DIR
AND DCMTK_dcmdata_LIBRARY
AND DCMTK_dcmimgle_INCLUDE_DIR
AND DCMTK_dcmimgle_LIBRARY )

  SET( DCMTK_FOUND YES )
  SET( DCMTK_INCLUDE_DIRS
${DCMTK_config_INCLUDE_DIR}
${DCMTK_ofstd_INCLUDE_DIR}
${DCMTK_dcmdata_INCLUDE_DIR}
${DCMTK_dcmimgle_INCLUDE_DIR}
  )

  SET( DCMTK_LIBRARIES
${DCMTK_dcmimgle_LIBRARY}
${DCMTK_dcmdata_LIBRARY}
${DCMTK_ofstd_LIBRARY}
${DCMTK_config_LIBRARY}
  )

  IF(DCMTK_imagedb_LIBRARY)
   SET( DCMTK_LIBRARIES
   ${DCMTK_LIBRARIES}
   ${DCMTK_imagedb_LIBRARY}
   )
  ENDIF(DCMTK_imagedb_LIBRARY)

  IF(DCMTK_dcmnet_LIBRARY)
   SET( DCMTK_LIBRARIES
   ${DCMTK_LIBRARIES}
   ${DCMTK_dcmnet_LIBRARY}
   )
  ENDIF(DCMTK_dcmnet_LIBRARY)

  IF( WIN32 )
SET( DCMTK_LIBRARIES ${DCMTK_LIBRARIES} netapi32 )
  ENDIF( WIN32 )

ENDIF( DCMTK_config_INCLUDE_DIR
AND DCMTK_ofstd_INCLUDE_DIR
AND DCMTK_ofstd_LIBRARY
AND DCMTK_dcmdata_INCLUDE_DIR
AND DCMTK_dcmdata_LIBRARY
AND DCMTK_dcmimgle_INCLUDE_DIR
AND DCMTK_dcmimgle_LIBRARY )

IF( NOT

Re: [osg-users] 2.8: XUL not completely found

2009-02-05 Thread Robert Osfield

HI Paul, I got the files OK each time, now reviewing...

Unfortunately the server is down so I won't be able to check any changes in...

On Thu, Feb 5, 2009 at 6:36 PM, Paul Melis
osg-us...@assumetheposition.nl wrote:
 Paul Melis wrote:
 Robert Osfield wrote:

 Hi Paul,

 I've just reviewed your modified FindXUL.cmake and found it to be
 identical to the one in OSG-2.8/svn/trunk.  Same problem as the mods
 for DCMTK...


 I must have sent you the versions from trunk, not the 2.8 branch.
 Here are the correct files.

 Dang, my thunderbird (on a fairly fresh system) wasn't updated to not
 send attachements inline. Here's the two files again...

 Paul

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found

2009-02-05 Thread Robert Osfield

Hi Paul,

I've tweaked the FindXUL.cmake to make the pkgconfig usage optional -
required as not all platforms have pkgconfig available.  The block now
looks like below segment.  The modified FindXUL.cmake is attached,
could you try this out?

Robert.

#use pkg-config to find various modues
INCLUDE(FindPkgConfig OPTIONAL)

IF(PKG_CONFIG_FOUND)

INCLUDE(FindPkgConfig)

pkg_check_modules(XULRUNNER_XPCOM xulrunner-xpcom)
pkg_check_modules(XULRUNNER_JS xulrunner-js)
pkg_check_modules(XULRUNNER_NSPR xulrunner-nspr)
pkg_check_modules(XULRUNNER_NSS xulrunner-nss)

ENDIF(PKG_CONFIG_FOUND)


FindXUL.cmake
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8: XUL not completely found