Re: [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. 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 ___ 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
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
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
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
Robert Osfield wrote: 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? Yep, seems to work fine. 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, 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
Re: [osg-users] 2.8: XUL not completely found
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\ Manager\\Environment;OSG_ROOT]/include /usr/freeware/include/mozjs /usr/freeware/include ) FIND_PATH(XUL_DIR NAMES components/appshell.xpt PATHS $ENV{OSG_DIR}/lib $ENV{OSG_DIR} $ENV{OSGDIR}/lib $ENV{OSGDIR} $ENV{OSG_ROOT}/lib ~/Library/Frameworks