It installs the _header files_ for openinventor. Can we kick the hell out of this? The bug is assigned to reavertm becaue media-libs/quarter is the only package depending on this that has a maintainer assigned. On the other hand, Dominik remember that if you commit an ebuild for a non-dev you *have* to take the proxing.
Diego, Coin3D is an open source OpenInventor implementation and it's supposed to install OpenInventor API compatible headers. Besides, Coin3D is being actively developed so more reasonable would be to kick OpenInventor from SGI instead. I'm not sure whether it's safe to install shared headers so that packages won't collide anymore. Mutual block on those packages would be more appropriate for now, I can try to slot them when I find some time to play with this.
Shouldn't the two have different include directories so that they are installed side-to-side then? If one wants to use coin, the pkg-config should tell you to use -I/usr/include/coin while using the original implementation would still be in /usr/include. Beside I guess you and ayoy should pick up the maintainership of this program, at this point.
Created attachment 213596 [details, diff] coin-3.1.2 -> coin-3.1.2-r1 - API headers displaced to /usr/include/coin/ - added static-libs USE flag Removing expat seems to be easy as well, unfortunately eautoreconf bails out and it's too much for my little brain to grasp.
Created attachment 213597 [details, diff] coin-3.1.2 -> coin-3.1.2-r1 (fixed 1 typo)
What about posting how exactly eautoreconf bails out?
(In reply to comment #5) > What about posting how exactly eautoreconf bails out? Hello, I like to say that I have agreed with Tommy[D] to maintain this package with him as a proxy. Roelof
(In reply to comment #6) > (In reply to comment #5) > > What about posting how exactly eautoreconf bails out? > > Hello, > > I like to say that I have agreed with Tommy[D] to maintain this package with > him as a proxy. > > Roelof > Hello, This is the answer of upstream about this problem Hi Roelof I think the correct solution here is to let Coin block Open Inventor and vice verse. Coin fully incorporates the Open Inventor API. Thus the correct solution might be to make Open Inventor a meta repository, and let Open Inventor and Coin be two alternative packages. Best regards Tom Fredrik
Well, there's no need anymore as patch I attached fixes file collisions. Remaining QA problem is just bundling expat and automake (aclocal to be precise) shebang that is involved here. I don't have build log atm (one can get it easily by overriding src_prepare and putting eautoreconf in last line), but the problem is coin provides already generated aclocal.m4 file and configure uses it extensively (they have rewritten many aclocal macros for some reason). Those macros are provided in cfg/coin.m4 but this file is not used during aclocal run so configure will bail out with not found macros being called. There may be some other problems as well.
(In reply to comment #8) > rewritten many aclocal macros for some reason). Those macros are provided in > cfg/coin.m4 but this file is not used during aclocal run so configure will bail > out with not found macros being called. There may be some other problems as > well. AT_M4DIR="${S}/cfg" eautoreconf
(In reply to comment #9) > (In reply to comment #8) > > rewritten many aclocal macros for some reason). Those macros are provided in > > cfg/coin.m4 but this file is not used during aclocal run so configure will bail > > out with not found macros being called. There may be some other problems as > > well. > AT_M4DIR="${S}/cfg" eautoreconf Oke, I will check the patch tommorrow against SoQt and report back. If everything works. I will adapt Coin and let Tommy[D] proxy the solution. Roelof
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > rewritten many aclocal macros for some reason). Those macros are provided in > > > cfg/coin.m4 but this file is not used during aclocal run so configure will bail > > > out with not found macros being called. There may be some other problems as > > > well. > > AT_M4DIR="${S}/cfg" eautoreconf > > > Oke, > > I will check the patch tommorrow against SoQt and report back. > If everything works. I will adapt Coin and let Tommy[D] proxy the solution. > > Roelof > Hello, I found a problem with this patch. If I want to compile freecad which depends on coin. First the compiling of freecad can't find the header files. I found them on /usr/include/coin/Inventor. After that the compiling can't find the devel files of Coin. Where are they with this patch. Roelof
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (In reply to comment #8) > > > > rewritten many aclocal macros for some reason). Those macros are provided in > > > > cfg/coin.m4 but this file is not used during aclocal run so configure will bail > > > > out with not found macros being called. There may be some other problems as > > > > well. > > > AT_M4DIR="${S}/cfg" eautoreconf > > > > > > Oke, > > > > I will check the patch tommorrow against SoQt and report back. > > If everything works. I will adapt Coin and let Tommy[D] proxy the solution. > > > > Roelof > > > > Hello, > > I found a problem with this patch. > If I want to compile freecad which depends on coin. First the compiling of > freecad can't find the header files. I found them on > /usr/include/coin/Inventor. > After that the compiling can't find the devel files of Coin. > Where are they with this patch. > > Roelof > Oke, Now I got this one working. Now testing the solution of Samuli Suominen for the expat problem. Roelof
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > (In reply to comment #9) > > > > (In reply to comment #8) > > > > > rewritten many aclocal macros for some reason). Those macros are provided in > > > > > cfg/coin.m4 but this file is not used during aclocal run so configure will bail > > > > > out with not found macros being called. There may be some other problems as > > > > > well. > > > > AT_M4DIR="${S}/cfg" eautoreconf > > > > > > > > > Oke, > > > > > > I will check the patch tommorrow against SoQt and report back. > > > If everything works. I will adapt Coin and let Tommy[D] proxy the solution. > > > > > > Roelof > > > > > > > Hello, > > > > I found a problem with this patch. > > If I want to compile freecad which depends on coin. First the compiling of > > freecad can't find the header files. I found them on > > /usr/include/coin/Inventor. > > After that the compiling can't find the devel files of Coin. > > Where are they with this patch. > > > > Roelof > > > > Oke, > > Now I got this one working. > Now testing the solution of Samuli Suominen for the expat problem. > > Roelof > Hello Samuli, This is not working. We now get this messages : ***** autoconf ***** ***** PWD: /var/tmp/portage/media-libs/coin-3.1.2/work/Coin-3.1.2 ***** autoconf configure.ac:63: error: possibly undefined macro: AC_DEFINE_UNQUOTED If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:68: error: possibly undefined macro: SIM_AC_DATE_RFC822 configure.ac:72: error: possibly undefined macro: SIM_AC_ISO8601_DATE configure.ac:75: error: possibly undefined macro: SIM_AC_MSVC_DSP_ENABLE_OPTION configure.ac:80: error: possibly undefined macro: SIM_AC_SETUP_MSVCPP_IFELSE configure.ac:94: error: possibly undefined macro: AC_ARG_ENABLE configure.ac:95: error: possibly undefined macro: AC_HELP_STRING configure.ac:143: error: possibly undefined macro: SIM_AC_CONFIGURATION_SETTING configure.ac:175: error: possibly undefined macro: SIM_AC_RELATIVE_SRC_DIR configure.ac:211: error: possibly undefined macro: SIM_AC_SETUP_MSVCRT configure.ac:228: error: possibly undefined macro: SIM_AC_UNIVERSAL_BINARIES configure.ac:268: error: possibly undefined macro: SIM_AC_MSC_VERSION configure.ac:276: error: possibly undefined macro: SIM_AC_STRIP_EXIT_DECLARATION configure.ac:280: error: possibly undefined macro: SIM_AC_MACOS10_DEPLOYMENT_TARGET configure.ac:287: error: possibly undefined macro: AC_DEFINE configure.ac:356: error: possibly undefined macro: SIM_AC_COMPILER_OPTIMIZATION configure.ac:359: error: possibly undefined macro: SIM_AC_COMPILER_CPLUSPLUS_FATAL_ERRORS configure.ac:362: error: possibly undefined macro: SIM_AC_CHECK_VAR_FUNCTIONNAME configure.ac:364: error: possibly undefined macro: SIM_AC_MAC_CPP_ADJUSTMENTS configure.ac:567: error: possibly undefined macro: AC_MSG_ERROR configure.ac:607: error: possibly undefined macro: SIM_AC_CHECK_PTHREAD configure.ac:669: error: possibly undefined macro: AC_CHECK_HEADERS configure.ac:681: error: possibly undefined macro: SIM_AC_CHECK_HEADER_TLHELP32_H configure.ac:682: error: possibly undefined macro: SIM_AC_CHECK_FUNC__SPLITPATH configure.ac:684: error: possibly undefined macro: SIM_AC_CHECK_WIN32_API configure.ac:750: error: possibly undefined macro: SIM_AC_DEFINE_BYTESIZE_TYPES configure.ac:829: error: possibly undefined macro: SIM_AC_CHECK_TYPEOF_STRUCT_MEMBER configure.ac:929: error: possibly undefined macro: SIM_AC_DOXYGEN_TOOL configure.ac:929: error: possibly undefined macro: SIM_AC_ERROR configure.ac:969: error: possibly undefined macro: SIM_AC_PACKAGEMAKER_APP configure.ac:1006: error: possibly undefined macro: SIM_AC_COMPILE_DEBUG configure.ac:1012: error: possibly undefined macro: SIM_AC_DEBUGSYMBOLS configure.ac:1013: error: possibly undefined macro: SIM_AC_RTTI_SUPPORT configure.ac:1014: error: possibly undefined macro: SIM_AC_EXCEPTION_HANDLING configure.ac:1015: error: possibly undefined macro: SIM_AC_PROFILING_SUPPORT configure.ac:1016: error: possibly undefined macro: SIM_AC_COMPILER_WARNINGS configure.ac:1017: error: possibly undefined macro: SIM_AC_DETECT_COMMON_COMPILER_FLAGS configure.ac:1060: error: possibly undefined macro: SIM_AC_CHECK_NPRINTF configure.ac:1075: error: possibly undefined macro: SIM_AC_CHECK_MACRO_QUOTE configure.ac:1302: error: possibly undefined macro: SIM_AC_CHECK_DYLD configure.ac:1315: error: possibly undefined macro: SIM_AC_CHECK_DL configure.ac:1326: error: possibly undefined macro: SIM_AC_CHECK_LOADLIBRARY configure.ac:1334: error: possibly undefined macro: SIM_AC_CHECK_DLD configure.ac:1359: error: possibly undefined macro: SIM_AC_ENABLE_ERROR configure.ac:1368: error: possibly undefined macro: SIM_AC_HAVE_SIMAGE_IFELSE configure.ac:1380: error: possibly undefined macro: AC_MSG_WARN configure.ac:1415: error: possibly undefined macro: SIM_AC_HAVE_OPENAL_IFELSE configure.ac:1467: error: possibly undefined macro: SIM_AC_HAVE_FONTCONFIG_IFELSE configure.ac:1509: error: possibly undefined macro: SIM_AC_HAVE_SPIDERMONKEY_IFELSE configure.ac:1557: error: possibly undefined macro: SIM_AC_HAVE_FREETYPE_IFELSE configure.ac:1580: error: possibly undefined macro: SIM_AC_CHECK_MATHLIB configure.ac:1618: error: possibly undefined macro: SIM_AC_HAVE_LIBZLIB_IFELSE configure.ac:1655: error: possibly undefined macro: SIM_AC_HAVE_LIBBZIP2_IFELSE configure.ac:1673: error: possibly undefined macro: SIM_AC_CHECK_X11 configure.ac:1681: error: possibly undefined macro: SIM_AC_CHECK_X11SHMEM Roelof
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > (In reply to comment #9) > > > > > (In reply to comment #8) > > > > > > rewritten many aclocal macros for some reason). Those macros are provided in > > > > > > cfg/coin.m4 but this file is not used during aclocal run so configure will bail > > > > > > out with not found macros being called. There may be some other problems as > > > > > > > > well. > > > > > AT_M4DIR="${S}/cfg" eautoreconf > > > > > > > > > > > > Oke, > > > > > > > > I will check the patch tommorrow against SoQt and report back. > > > > If everything works. I will adapt Coin and let Tommy[D] proxy the solution. > > > > > > > > Roelof > > > > > > > > > > Hello, > > > > > > I found a problem with this patch. > > > If I want to compile freecad which depends on coin. First the compiling of > > > freecad can't find the header files. I found them on > > > /usr/include/coin/Inventor. > > > After that the compiling can't find the devel files of Coin. > > > Where are they with this patch. > > > > > > Roelof > > > > > > > Oke, > > > > Now I got this one working. > > Now testing the solution of Samuli Suominen for the expat problem. > > > > Roelof > > > > Hello Samuli, > > This is not working. We now get this messages : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ***** autoconf ***** > ***** PWD: /var/tmp/portage/media-libs/coin-3.1.2/work/Coin-3.1.2 > ***** autoconf > > configure.ac:63: error: possibly undefined macro: AC_DEFINE_UNQUOTED > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure.ac:68: error: possibly undefined macro: SIM_AC_DATE_RFC822 > configure.ac:72: error: possibly undefined macro: SIM_AC_ISO8601_DATE > configure.ac:75: error: possibly undefined macro: SIM_AC_MSVC_DSP_ENABLE_OPTION > configure.ac:80: error: possibly undefined macro: SIM_AC_SETUP_MSVCPP_IFELSE > configure.ac:94: error: possibly undefined macro: AC_ARG_ENABLE > configure.ac:95: error: possibly undefined macro: AC_HELP_STRING > configure.ac:143: error: possibly undefined macro: SIM_AC_CONFIGURATION_SETTING > configure.ac:175: error: possibly undefined macro: SIM_AC_RELATIVE_SRC_DIR > configure.ac:211: error: possibly undefined macro: SIM_AC_SETUP_MSVCRT > configure.ac:228: error: possibly undefined macro: SIM_AC_UNIVERSAL_BINARIES > configure.ac:268: error: possibly undefined macro: SIM_AC_MSC_VERSION > configure.ac:276: error: possibly undefined macro: > SIM_AC_STRIP_EXIT_DECLARATION > configure.ac:280: error: possibly undefined macro: > SIM_AC_MACOS10_DEPLOYMENT_TARGET > configure.ac:287: error: possibly undefined macro: AC_DEFINE > configure.ac:356: error: possibly undefined macro: SIM_AC_COMPILER_OPTIMIZATION > configure.ac:359: error: possibly undefined macro: > SIM_AC_COMPILER_CPLUSPLUS_FATAL_ERRORS > configure.ac:362: error: possibly undefined macro: > SIM_AC_CHECK_VAR_FUNCTIONNAME > configure.ac:364: error: possibly undefined macro: SIM_AC_MAC_CPP_ADJUSTMENTS > configure.ac:567: error: possibly undefined macro: AC_MSG_ERROR > configure.ac:607: error: possibly undefined macro: SIM_AC_CHECK_PTHREAD > configure.ac:669: error: possibly undefined macro: AC_CHECK_HEADERS > configure.ac:681: error: possibly undefined macro: > SIM_AC_CHECK_HEADER_TLHELP32_H > configure.ac:682: error: possibly undefined macro: SIM_AC_CHECK_FUNC__SPLITPATH > configure.ac:684: error: possibly undefined macro: SIM_AC_CHECK_WIN32_API > configure.ac:750: error: possibly undefined macro: SIM_AC_DEFINE_BYTESIZE_TYPES > configure.ac:829: error: possibly undefined macro: > SIM_AC_CHECK_TYPEOF_STRUCT_MEMBER > configure.ac:929: error: possibly undefined macro: SIM_AC_DOXYGEN_TOOL > configure.ac:929: error: possibly undefined macro: SIM_AC_ERROR > configure.ac:969: error: possibly undefined macro: SIM_AC_PACKAGEMAKER_APP > configure.ac:1006: error: possibly undefined macro: SIM_AC_COMPILE_DEBUG > configure.ac:1012: error: possibly undefined macro: SIM_AC_DEBUGSYMBOLS > configure.ac:1013: error: possibly undefined macro: SIM_AC_RTTI_SUPPORT > configure.ac:1014: error: possibly undefined macro: SIM_AC_EXCEPTION_HANDLING > configure.ac:1015: error: possibly undefined macro: SIM_AC_PROFILING_SUPPORT > configure.ac:1016: error: possibly undefined macro: SIM_AC_COMPILER_WARNINGS > configure.ac:1017: error: possibly undefined macro: > SIM_AC_DETECT_COMMON_COMPILER_FLAGS > configure.ac:1060: error: possibly undefined macro: SIM_AC_CHECK_NPRINTF > configure.ac:1075: error: possibly undefined macro: SIM_AC_CHECK_MACRO_QUOTE > configure.ac:1302: error: possibly undefined macro: SIM_AC_CHECK_DYLD > configure.ac:1315: error: possibly undefined macro: SIM_AC_CHECK_DL > configure.ac:1326: error: possibly undefined macro: SIM_AC_CHECK_LOADLIBRARY > configure.ac:1334: error: possibly undefined macro: SIM_AC_CHECK_DLD > configure.ac:1359: error: possibly undefined macro: SIM_AC_ENABLE_ERROR > configure.ac:1368: error: possibly undefined macro: SIM_AC_HAVE_SIMAGE_IFELSE > configure.ac:1380: error: possibly undefined macro: AC_MSG_WARN > configure.ac:1415: error: possibly undefined macro: SIM_AC_HAVE_OPENAL_IFELSE > configure.ac:1467: error: possibly undefined macro: > SIM_AC_HAVE_FONTCONFIG_IFELSE > configure.ac:1509: error: possibly undefined macro: > SIM_AC_HAVE_SPIDERMONKEY_IFELSE > configure.ac:1557: error: possibly undefined macro: SIM_AC_HAVE_FREETYPE_IFELSE > configure.ac:1580: error: possibly undefined macro: SIM_AC_CHECK_MATHLIB > configure.ac:1618: error: possibly undefined macro: SIM_AC_HAVE_LIBZLIB_IFELSE > configure.ac:1655: error: possibly undefined macro: SIM_AC_HAVE_LIBBZIP2_IFELSE > configure.ac:1673: error: possibly undefined macro: SIM_AC_CHECK_X11 > configure.ac:1681: error: possibly undefined macro: SIM_AC_CHECK_X11SHMEM > > > Roelof > hello, What's the problem with expat now. If I use the patch I don't see any file collisions or any problem if I emerged expat ? Roelof
Hello Diego, Are you happy concerning Q & A with the movement of OPeninventor ? Roelof
These SIM_ errors are because of missing simage.m4, that's media-libs/simage from bug 197209.
(In reply to comment #17) > These SIM_ errors are because of missing simage.m4, that's media-libs/simage > from bug 197209. > Oke, That's easy to fix. So we can solve two problems at once. Only problem is that the ebuild for simage in not in main tree or in any overlay as far as I know. Roelof
(In reply to comment #18) > (In reply to comment #17) > > These SIM_ errors are because of missing simage.m4, that's media-libs/simage > > from bug 197209. > > > > Oke, > > That's easy to fix. So we can solve two problems at once. > Only problem is that the ebuild for simage in not in main tree or in any > overlay as far as I know. > > Roelof > Hello Samuli, First emerging simage and then emerging Coin doesn't solve the problem. Still get the undefined error messages. Roelof
Hi I'm one of the Coin/Quarter/SoQt maintainers. Regarding the expat library used. We are reacting to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560928 and will implement a configure flag --enable-system-expat. So we'll look into that. As for the bootstrapping you are trying to do, it seems you are trying to bootstrap without using simacros. The .m4 files are available at http://hg.sim.no/simacros/default/ as a Mercurial repository. I'm having a bit of trouble understanding if there are more problems here, but if there are, please restate them.
(In reply to comment #20) > I'm having a bit of trouble understanding if there are more problems here, but > if there are, please restate them. That's about it. But it would be helpful if you could include the .m4 macros in the source tarball with next release, never know when one needs to autoreconf (bootstrap) again for another not-yet-known issue.
(In reply to comment #21) > (In reply to comment #20) > > I'm having a bit of trouble understanding if there are more problems here, but > > if there are, please restate them. > > That's about it. But it would be helpful if you could include the .m4 macros in > the source tarball with next release, never know when one needs to autoreconf > (bootstrap) again for another not-yet-known issue. > Hello Sumili. I'm a little bit further on solving this. When I change the m4 to AT_M4DIR= -I ${S}/cfg eautoreconf -I /usr/share/aclocal/simage.m4 the configure goes well but the make chrashes with a sandbox violation. I see then this message: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-13796.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: mkdir S: deny P: /Inventor A: /Inventor R: /Inventor C: mkdir -p -- /var/tmp/portage/media-libs/coin-3.1.2/image//usr/include/coin /Inventor C/XML -------------------------------------------------------------------------------- * QA Notice: command not found: * * /var/tmp/portage/media-libs/coin-3.1.2/temp/environment: line 2823: -I: command not found * /var/tmp/portage/media-libs/coin-3.1.2/temp/environment: line 2820: --enable-3ds-import: command not found * /var/tmp/portage/media-libs/coin-3.1.2/temp/environment: line 2821: --disable-sound: command not Roelof
Hello Tom, BEcause we don't want the same problems with Openinventor as now with expat we would like the same solution for Openinventor. So we can use the external Openinventor files instead of the built in Openinventor files. Roelof
For the OpenInventor headers, if it implements the same interface, it should probably install them in an offset (like /usr/include/coin/OpenInventor) and have the offset directory added to the include path by pkg-config (-I/usr/include/coin).
(In reply to comment #24) > For the OpenInventor headers, if it implements the same interface, it should > probably install them in an offset (like /usr/include/coin/OpenInventor) and > have the offset directory added to the include path by pkg-config > (-I/usr/include/coin). > Hello Diego, How so saitisfied with this solution. There's still a chance that a bug in openinventor stays in the system. Or am I mistaken. Roelof
There is absolutely no chance we will implement an option that uses Open Inventor (OIV) headers. That's totally unrelated to the expat issue. Expat is a library we use in order to provide xml parsing facilities inside Coin. We have chosen to embed it because we compile on different systems, among these MS Windows, which usually does not provide us with an expat library. We thought of this as a convenience, rather than a hazzle. When arguing the pros and cons, we came to the conclusion that providing an option for the end user is reasonable. Using OIV headers is not an option. Coin is an OIV clone, an is fully API compatible with OIV. The other way around is not true. This means that all Coin headers will define the same functions as the OIV header, but it may define additional functions. I can see no good reasons for keeping OIV and Coin on the same system. The only reason I can think of is comparing the two. Please feel free to educate me, if I'm too narrow minded here. There are other OIV clones out there like the vsg3d implementation. Coin and vsg3d are not API compatible, so there is clearly the case for installing these side by side. Anyway, we will not do anything do facilitate installing OIV and Coin side by side. If you choose to do this against my advice, there are already the necessary facilities available in configure for fine tuning where to install the different files, eg. --includedir=DIR Diego seems to have fully understood how to accomplish this, but again I think its totally unnecessary to do so.
(In reply to comment #21) > (In reply to comment #20) > > I'm having a bit of trouble understanding if there are more problems here, but > > if there are, please restate them. > > That's about it. But it would be helpful if you could include the .m4 macros in > the source tarball with next release, never know when one needs to autoreconf > (bootstrap) again for another not-yet-known issue. I can see the case for that, still I don't think this is something a regular developer should ever have to think about. The simacros repository provides a system which allows anyone desiring to develop on Coin or any of the related repositories a fully integrated bootstrap environment. I think if it is necessary to patch anything, it should be sufficient to bootstrap using the recommended procedure(simacros), and then apply the patch directly to the configure/Makefile.in files. But then again, when I'm writing this, perhaps we can actually provide this convenience directly, by adding a bootstrap script which downloads the bootstrap files, configures the bootstrap environment, and bootstraps. Ensnaring thought. Not a top priority though, but I'll put it down in the backlog.
Hi Tom As for using simacros to develop applications using Coin - it's much easier to use CMake for it. I really think you would be much better off using CMake for building Coin as well. (that's whole buildsytem needed to use Coin in CMake controlled app to compile and link some test program) " project (test) cmake_minimum_required (VERSION 2.6) find_package (Coin3D REQUIRED) find_package (PkgConfig REQUIRED) pkg_check_modules (Quarter REQUIRED Quarter>=1.0.0) include_directories (${COIN3D_INCLUDES} ${Quarter_INCLUDE_DIRS}) set (TEST_SOURCES main.cpp) add_executable (test ${TEST_SOURCES}) target_link_libraries (test ${COIN3D_LIBRARIES} ${Quarter_LDFLAGS}) " I know Diego will probably disagree here but it would probably take much less time to write whole CMake buildsystem from scratch than sorting out this particular autotools issue - at least for me, besides you don't loose any multiplatform compatibility and it's *much* easier to maintain and much easier to work with for distro packagers (anything KDE4 is prime example). As for headers, since I patched Coin ebuild already in #3 to install headers in /usr/include/coin subdirectory - I don't think it was worthy bringing up here again - the only remaining issue seems to be one from #22.
(In reply to comment #28) > Hi Tom > > As for using simacros to develop applications using Coin - it's much easier to > use CMake for it. I really think you would be much better off using CMake for > building Coin as well. Let's just put it like this, I'm not the person that needs to be convinced about that. You're oversimplifying a bit, but by and large I agree.
(In reply to comment #29) > (In reply to comment #28) > > Hi Tom > > > > As for using simacros to develop applications using Coin - it's much easier to > > use CMake for it. I really think you would be much better off using CMake for > > building Coin as well. > Let's just put it like this, I'm not the person that needs to be convinced > about that. > You're oversimplifying a bit, but by and large I agree. Oke, What is now the way to go. Still trying to solve the configure and make part or wait till there is a cmake ? Roelof
No no, of course making autotools work is the way to go.
(In reply to comment #31) > No no, of course making autotools work is the way to go. > Oke, Then I have to look further how to put in two directory's for At_m4. Roelof
Really, if Tom can look into making expat optional with a (not-too-distant) next release, I'd sincerely not say much about waiting on that. If you already fixed the --includedir parameter (which reduces quite a bit the problem on my side), then it should be fine for now, and let's wait on expat.
(In reply to comment #33) > Really, if Tom can look into making expat optional with a (not-too-distant) > next release, I'd sincerely not say much about waiting on that. > > If you already fixed the --includedir parameter (which reduces quite a bit the > problem on my side), then it should be fine for now, and let's wait on expat. > Fine by me. Then I put this patch with the solution of two other Coin bugs in the next ebuild. Before I can make this ebuild. I have to wait for one answer fom tom for a Coin/Wine problem. Roelof
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > Hi Tom > > > > > > As for using simacros to develop applications using Coin - it's much easier to > > > use CMake for it. I really think you would be much better off using CMake for > > > building Coin as well. > > Let's just put it like this, I'm not the person that needs to be convinced > > about that. > > You're oversimplifying a bit, but by and large I agree. > > Oke, > > What is now the way to go. > Still trying to solve the configure and make part or wait till there is a cmake > ? I am not the sole developer of Coin, and I cannot decide on switching buildsystem. What I'm saying is that I am in support of such a switch, but that switch will not happen in the near future. I will handle the autopain (configure issue).
(In reply to comment #35) > (In reply to comment #30) > > (In reply to comment #29) > > > (In reply to comment #28) > > > > Hi Tom > > > > > > > > As for using simacros to develop applications using Coin - it's much easier to > > > > use CMake for it. I really think you would be much better off using CMake for > > > > building Coin as well. > > > Let's just put it like this, I'm not the person that needs to be convinced > > > about that. > > > You're oversimplifying a bit, but by and large I agree. > > > > Oke, > > > > What is now the way to go. > > Still trying to solve the configure and make part or wait till there is a cmake > > ? > > I am not the sole developer of Coin, and I cannot decide on switching > buildsystem. What I'm saying is that I am in support of such a switch, but that > switch will not happen in the near future. I will handle the autopain > (configure issue). > Hello Tom, Are you saying that you try to solve the expat problem. That part will be solved as soon as the expat swith will be in Coin so we wait to that. Roelof
(In reply to comment #36) > (In reply to comment #35) > > (In reply to comment #30) > > > (In reply to comment #29) > > > > (In reply to comment #28) > > > > > Hi Tom > > > > > > > > > > As for using simacros to develop applications using Coin - it's much easier to > > > > > use CMake for it. I really think you would be much better off using CMake for > > > > > building Coin as well. > > > > Let's just put it like this, I'm not the person that needs to be convinced > > > > about that. > > > > You're oversimplifying a bit, but by and large I agree. > > > > > > Oke, > > > > > > What is now the way to go. > > > Still trying to solve the configure and make part or wait till there is a cmake > > > ? > > > > I am not the sole developer of Coin, and I cannot decide on switching > > buildsystem. What I'm saying is that I am in support of such a switch, but that > > switch will not happen in the near future. I will handle the autopain > > (configure issue). > > > > Hello Tom, > > Are you saying that you try to solve the expat problem. > That part will be solved as soon as the expat swith will be in Coin so we wait > to that. Yes, I will handle the expat issue.
(In reply to comment #37) > (In reply to comment #36) > > (In reply to comment #35) > > > (In reply to comment #30) > > > > (In reply to comment #29) > > > > > (In reply to comment #28) > > > > > > Hi Tom > > > > > > > > > > > > As for using simacros to develop applications using Coin - it's much easier to > > > > > > use CMake for it. I really think you would be much better off using CMake for > > > > > > building Coin as well. > > > > > Let's just put it like this, I'm not the person that needs to be convinced > > > > > about that. > > > > > You're oversimplifying a bit, but by and large I agree. > > > > > > > > Oke, > > > > > > > > What is now the way to go. > > > > Still trying to solve the configure and make part or wait till there is a cmake > > > > ? > > > > > > I am not the sole developer of Coin, and I cannot decide on switching > > > buildsystem. What I'm saying is that I am in support of such a switch, but that > > > switch will not happen in the near future. I will handle the autopain > > > (configure issue). > > > > > > > Hello Tom, > > > > Are you saying that you try to solve the expat problem. > > That part will be solved as soon as the expat swith will be in Coin so we wait > > to that. > > Yes, I will handle the expat issue. > Oke. If it's allright with the others we wait for the solution. Roelof
I have fixed the conditional expat issue in the development version of Coin 4.0.0a. Please provide me with a list of versions you desire me to patch.
(In reply to comment #39) > I have fixed the conditional expat issue in the development version of Coin > 4.0.0a. > > Please provide me with a list of versions you desire me to patch. > Hello Tom, We use here on gentoo version 3.1.0 en version 3.1.2. Roelof
These patches works for the entire 3.1 series: Fix (#2): http://hg.sim.no/Coin/coin-3.1/raw-rev/06d276e6894e Follow-up bootstrap (#3). http://hg.sim.no/Coin/coin-3.1/raw-rev/ac55d7d433aa See also new bootstrap which fixes the expat issue (#1): http://hg.sim.no/Coin/coin-3.1/raw-rev/bc9af655d248 Number in parenthesis is the order the patches are applied, with #1 first.
(In reply to comment #41) > These patches works for the entire 3.1 series: > > Fix (#2): > http://hg.sim.no/Coin/coin-3.1/raw-rev/06d276e6894e > > Follow-up bootstrap (#3). > http://hg.sim.no/Coin/coin-3.1/raw-rev/ac55d7d433aa > > See also new bootstrap which fixes the expat issue (#1): > http://hg.sim.no/Coin/coin-3.1/raw-rev/bc9af655d248 > > Number in parenthesis is the order the patches are applied, with #1 first. > Hello Tom, I will test this patches also. Do I need every patch ? Roelof
Created attachment 216243 [details] new ebuild for Coin 3.1.0. Hello, I made a new ebuild for 3.1.0 with all the patches provided. I hope Q&A will be happy now. If so, I will solve bug 197209 and bug 291888 also. Roelof
> See also new bootstrap which fixes the expat issue (#1): > http://hg.sim.no/Coin/coin-3.1/raw-rev/bc9af655d248 That should be fixes the wine issue, not the expat issue.
(In reply to comment #44) > > See also new bootstrap which fixes the expat issue (#1): > > http://hg.sim.no/Coin/coin-3.1/raw-rev/bc9af655d248 > > That should be fixes the wine issue, not the expat issue. > Oke, Thanks for the clarification. Roelof
Unfortunately --enable-system-expat has no effect, -DUSE_SYSTEM_EXPAT is not appendend as compiler definition, and when manually added, it will use expat static library. Please start providing .m4 files so that we can actually do something about it, patching configure or Makefile.in files is not an option. Other issue are: - broken SpiderMonkey check when trying link-time spidermonkey linking (conftest is .cpp file and provided spidermonkey test program does not compile as it contains invalid (in C++) pointer cast. - the same test is unable to locate spidermonkey library (empty -l is appended to linker) - freetype check could use pkg-config (actually most tests could use pkg-config if provided by package)
ugh...
I take the UGH to mean this is still an issue. I haven't done Coin development for a long time now, and stopped using Gentoo as well. But it seems there is an active community maintaining it over at https://bitbucket.org/Coin3D/coin/wiki/Home
4.0.0a (which is now in ~arch) uses system expat. I think I'll work towards getting this stabilised (given it's much easier to maintain for me than 3.1.3).
(In reply to Maciej Mrozowski from comment #49) > 4.0.0a (which is now in ~arch) uses system expat. I think I'll work towards > getting this stabilised (given it's much easier to maintain for me than > 3.1.3). How is this looking?
https://bugs.gentoo.org/744901 reported
coin-4.0.0 is now stable.
