TOra / Bugs / #873 Bundled libs

Ivan Brezina - 2013-10-21

Which ones are bothering you?

libantlr3c - it does not make sense to use system provided library. ANTLR versions are not backward not forward compatible. We must use EXACTLY the same version as our parser files. This library is not mandatory and will be deleted soon.

libantlr3cpp - this is header only library. So far it was not packaged. Also contains some fixes not yet pulled into trunk.

liberrmodel - this library was not packaged yet by anybody. It's planar graph drawing library made as an extract from kgraphviewer. Tora specific library not used by any other project.

Loki - Header only library. Theoretically we could use distribution one (with one exception)

qscintilla2 - used mostly for Windows builds - not recommended to use on Linux.

stack - Tora specific library not used by any other project

trotl - Tora specific library not used by any other project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Hubbitus - 2013-10-22

Hello Ivan.
Thanks to the answer.
For the libraries which is part of tora project we can leave its here. If such may be not used please say switch, option how to archive that - I'll then just remove it before build. All other must be unbundled as condition to hit Fedora. If you are interesting and ready start that work on tora side I could package required libraries also.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ivan Brezina - 2013-10-22

I think you first should check this thread:
https://sourceforge.net/p/tora/mailman/message/31549255/

Petr is working on SUSE packages.

Now about the libraries in extlibs forlder

libantlr3c-3.3 - ANTLR C runtime libs. Are not needed at this moment as we are going to use C++ runtime libs. Feel free to delete it

libantlr3cpp-3.5.1 - ANTLR C++ runtime libs. Not packaged yet and library API is still under development.
ANTLR is good candidate for an exception. ANTLR versions are not backward nor forward compatible and rest of our parser generated sources (src/parsing/)
depend on EXACT ANRLR version. There is no other way of doing that. It does not make any sense to package this anyway.
Or you would have to do it like libpng does. You would end up with several packages named libantlr32 libantlr33 libantlr34 libantlr35 libantlr351 libantlr352.

libermodel - Tora specific library. Not used by any other project

loki - the most problematic one. There are several forks of this library and I do not know which one to choose and I do not want waste my time searching for the right one.
We use only very limited subset of library features, but anyway I had to add few patches in it. I'm trying to build Tora on Ubuntu with distrib. version and it does not work.
This thinks that long long int is not a numerical datatype. I'm afraid I would have to push my fixes into all the distributions. It does not seem to be realistic.
Just try to compare the contents of extlibs/loki/include with the package(s) provided by Fedora.

loki-extra - One header only - not a library. Alternative Factory implementation.

parsing

parsing.cpp
These are not libraries but sandboxes for various tests. These are excluded from the build anyway

qscintilla2
Excluded from default build. Attached mostly for Windows builds. But on the other hand I must say that this contemporary version has many handy fixes.

stack - Tora specific library. Used only for debug builds.

trotl - Tora specific library. C++ OCI wrapper. This one must stay.

Just try to delete libraries you do not like and remove reference in extlibs/CMakeLists.txt

At this moment the default build does not use:
- loki (it tries to use distrib one but it does not work)
- qscintilla2 (also not included in default build)
- stack - is excluded if you use -DCMAKE_BUILD_TYPE=Release

Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Hubbitus - 2013-10-23
  
  loki - the most problematic one. There are several forks of this library and I do not know which one to choose and I do not want waste my time searching for the right one.
  …
  I'm afraid I would have to push my fixes into all the distributions. It does not seem to be realistic.
  
  Did you tried push your patches to upstream loki authors?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Ivan Brezina - 2013-10-23
    
    No. finally I have found a workaround(or proper solution). Now it can be compiled with distribution provided header.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Hubbitus - 2013-10-26
  
  libantlr3cpp-3.5.1 - ANTLR C++ runtime libs. Not packaged yet and library API is still under development.
  ANTLR is good candidate for an exception. ANTLR versions are not backward nor forward compatible and rest of our parser generated sources (src/parsing/)
  depend on EXACT ANRLR version. There is no other way of doing that. It does not make any sense to package this anyway.
  Or you would have to do it like libpng does. You would end up with several packages named libantlr32 libantlr33 libantlr34 libantlr35 libantlr351 libantlr352.
  
  If i understand correctly it is just C++ wrapper under antlr3 library? Last already packaged:
  ant-antlr3.noarch : Antlr3 task for Ant
  ant-antlr3-javadoc.noarch : Javadoc for ant-antlr3
  antlr3-debuginfo.x86_64 : Debug information for package antlr3
  antlr3-C.x86_64 : C run-time support for ANTLR-generated parsers
  antlr3-C-devel.i686 : Header files for the C bindings for ANTLR-generated parsers
  antlr3-C-devel.x86_64 : Header files for the C bindings for ANTLR-generated parsers
  antlr3-C-docs.noarch : API documentation for the C run-time support for ANTLR-generated parsers
  antlr3-java.noarch : Java run-time support for ANTLR-generated parsers
  antlr3-javascript.noarch : Javascript run-time support for ANTLR-generated parsers
  antlr3-tool.noarch : ANother Tool for Language Recognition
  
  Could you please point me on its site?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Ivan Brezina - 2013-10-26
    
    No it is not a wrapper. It is alternative C++ implementation. And is it compatible with the ANTLR tool ver. 3.5.1. While Fedora has packaged ver 3.4 of C runtime.
    As I stated several times before. ANTLR versions are not backward nor forward compatible. The code generated with version 3.4 will not work with runtimme ver. 3.5 and vice versa. Moreover the version shipped with Fedora is buggy as hell. Also it does not make any sense to name the package antlr3 - behavirour of such a package is unpredicable.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Hubbitus - 2013-10-28
      
      Could you please point me on project site?
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Ivan Brezina - 2013-10-28
        
        It's http://www.antlr3.org. Also hosted on github: https://github.com/antlr/antlr3
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Hubbitus - 2013-11-03
        
        Is last 4.1 version satisfy Tora needs?
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Ivan Brezina - 2013-11-03
        
        Version 4,x supports Java na C# only. So far nobody started working on C/C++ support.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Hubbitus - 2013-11-03
        
        What last version is support C++? Does it satisfy tora needs? I then just may (try) ask maintainer update it Fedora.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Ivan Brezina - 2013-11-04
        
        I'm afraid this discussion leads to nowhere. Tora works with the latest trunk (plus needs several patches on top of it). The C++ runtime port was not packaged yet and most likely it's API will change before it gets packaged.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Hubbitus - 2013-11-04
        
        Sorry for I insist. But with you help I be able remove all external libraries except that. So far thank you very much. So, I search possibility do it with it also. If it absolutely not possible I'll try fill request to exception ( https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions ), but for it I also should have awesome arguments. Did you tried push tora patches against antlr3 to upstream?
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Ivan Brezina - 2013-11-04
        
        * Yes - see https://github.com/antlr/antlr3/pulls - pull request 129 * Fedora/RHEL use package 3.4 * ver 3.4 is not 100% compatible with current version 3.5.1 * ver 3.5.1 is not 100% compatible with version 3.4 * ver 3.4 (C runtime)included in RHEL segfaults. See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=966973. The pull request 43 was created by MySQLWorkbech authors. So far not aplied into upstream nor included in RHEL package. * neither of RHEL/Fedora packages include C++ runtime * I expect that the C++ runtime API will slightly change in the future * ANTLR C++ runtime is quite new and only few projects use it * ANTLR C++ runtime is not a library at all. It is set of 45 headers. It does have any binaries
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Hubbitus - 2013-11-07
        
        Thank you very much for help.
        I'he fill update request - https://bugzilla.redhat.com/show_bug.cgi?id=1026440
        Waiting answer. Then will deal dependant on solution (have dep, or try request exception).
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Ivan Brezina - 2013-11-07
        
        Good to hear. It started moving - somehow: see: https://github.com/antlr/antlr3/pull/43. But anyway I still think the "only" solution for Fedora would be to have two packages named: antlr34, antlr35. It is not soo easy to switch from one version onto another one. Can you tell how many projects in Fedora do depend on antlr?
        
        Last edit: Ivan Brezina 2013-11-07
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Hubbitus - 2013-11-07
        
        Glad to heard also, thanks.
        
        repoquery --whatrequire 'antlr*'
        
        OmegaT-0:2.6.1-0.9.Beta.fc19.x86_64
        ant-antlr-0:1.8.4-6.fc19.noarch
        antlr-maven-plugin-0:2.2-9.fc19.noarch
        antlr3-C-devel-0:3.4-14.fc19.i686
        antlr3-C-devel-0:3.4-14.fc19.x86_64
        antlr3-C-docs-0:3.4-14.fc19.noarch
        antlr3-tool-0:3.4-14.fc19.noarch
        antlrworks-0:1.4.3-8.fc19.noarch
        apacheds-shared-0:0.9.19-3.fc19.noarch
        checkstyle-0:5.6-5.fc19.noarch
        eclipse-checkstyle-0:5.1.0-8.fc19.noarch
        eclipse-epic-0:0.6.44-3.fc19.noarch
        eclipselink-0:2.3.2-2.fc19.noarch
        eucalyptus-common-java-0:3.2.1-3.fc19.x86_64
        glassfish-toplink-essentials-0:2.0.46-5.fc19.noarch
        gluegen-0:1-0.20102506svn15.fc19.x86_64
        gmaven-0:1.4-4.fc19.noarch
        gradle-0:1.0-13.fc19.noarch
        groovy-0:1.8.8-4.fc19.noarch
        groovy-0:1.8.9-4.fc19.noarch
        groovy18-0:1.8.9-3.fc19.noarch
        hibernate-0:4.1.7-6.fc19.noarch
        jabref-0:2.9.2-1.fc19.noarch
        jacorb-0:2.3.1-5.fc19.noarch
        jacorb-0:2.3.1-8.fc19.noarch
        jboss-as-0:7.1.1-19.fc19.noarch
        jboss-as-0:7.1.1-21.fc19.noarch
        jboss-jts-0:4.16.2-11.fc19.noarch
        jgettext-0:0.13-2.fc19.noarch
        mysql-workbench-0:5.2.47-2.fc19.x86_64
        ovirt-engine-backend-0:3.1.0-1.fc19.noarch
        python-xlwt-0:0.7.4-3.fc19.noarch
        sqljet-0:1.1.4-4.fc19.noarch
        stringtemplate-0:3.2.1-5.fc19.noarch
        struts-0:1.3.10-7.fc19.noarch
        ws-jaxme-0:0.5.2-8.fc19.noarch
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Ivan Brezina - 2013-11-08
        
        That's bad. I do not believe, that all these projects can be modified to use newest ANTLR version. EclipseLink and Jboss? No way.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Hubbitus - 2013-11-09
        
        May be with java backward compatibility there better situation? Anyway my request assigned and I think we should await few days answer from maintainer.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Hubbitus - 2013-10-26
  
  Unfortunately trotl unconditionally search Oracle libraries even besides -DENABLE_ORACLE:BOOLEAN=false and then fail:
  
  /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DPOSTGRESQL_PATH_INCLUDES=/usr/include -DENABLE_ORACLE:BOOLEAN=false
  Qt4 Found OK
  QScintilla2 Found OK
  
  CMake Error at extlibs/trotl/CMakeLists.txt:76 (MESSAGE):
  No Oracle client found
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Ivan Brezina - 2013-10-26
    
    Ok fixed in trunk, although it does not make to much sense. (To build "Tool for Oracle" without Oracle support). Support for MySQL and PostgreSQL is still heavily experimental. So far we do not have any maintainer for these.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Hubbitus - 2013-10-28
      
      Thank you.
      Unfortunately Oracle is not free software. So in Fedora we can ship only Postgres and MySQL support only. But in spec leaved two strings to just uncomment end recompile src.rpm for whom need it. I hope.
      Personally I've used it for Postgresql.
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Ivan Brezina - 2013-10-28
        
        You do not have to ship Oracle libs. Just compile Tora with Oracle connector plugin. So far we do not have any maintainer for MySQL nor PostgeSQL port. It's still experimental and a lot for work have to be done.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Hubbitus - 2013-10-28
      
      Additionally trunc revision 4913 failed with:
      
      CMake Error at src/CMakeLists.txt:1060 (ADD_EXECUTABLE): Cannot find source file: connection/moc_tooraclesetting.cxx Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bundled libs

Group

Searches

Help

#873 Bundled libs

Discussion

repoquery --whatrequire 'antlr*'