From: <iv...@cv...> - 2013-10-22 15:00:13
|
Quoting Petr Vanek <pe...@ya...>: > good idea. > > The spec file for suse is much smaller and simpler now with tora3. i use > 2.99.<svnrev> version for these packages. > RPM packages are available at http://download.yarpen.cz and I'll setup a > cron job for daily rebuild from SVN. > > What are suggested cmake options for packaging, please? Now I would use "-DCMAKE_BUILD_TYPE=Debug" this will imply - no inline functions - CXXFLAGS=-O0 (no optimalizations) - resulting "nice" readable stack traces and core dumps - logging on screen - logging into logging docklet - stack traces in exceptions thrown from trotl lib > My idea is to have similar features in all distros (I'm preparing suse > packages in the Packman repository which allows to build packages > against instantclient). > > I use this setup (oracle instantclient uses oracle-devel alias): > > BuildRequires: ImageMagick > BuildRequires: boost-devel > BuildRequires: cmake > BuildRequires: doxygen > BuildRequires: hicolor-icon-theme > BuildRequires: libqscintilla-devel > BuildRequires: libqt4-devel > BuildRequires: oracle-devel > BuildRequires: postgresql-devel > BuildRequires: update-desktop-files > BuildRequires: graphviz-devel > BuildRequires: libpoppler-qt4-devel > BuildRequires: pkgconfig(libgvc) > BuildRequires: pkgconfig(libcdt) > BuildRequires: pkgconfig(libgraph) > BuildRequires: pkgconfig(libpathplan) I would also add loki-devel. Some Fedora packager requested we should use system Loki lib instead of our bundled one. The problem with Loki lib is that there are several forks of it and I do not know which one to choose. > > > cmake \ > -DCMAKE_BUILD_TYPE=RELWITHDEBINFO \ > -DCMAKE_VERBOSE_MAKEFILE=TRUE \ > -DCMAKE_INSTALL_PREFIX="%{_prefix}" \ > -DORACLE_PATH_INCLUDES="/usr/include/oracle/%oracle_version/%client" \ > -DORACLE_PATH_LIB="$ORACLE_HOME" \ > -DCMAKE_SKIP_RPATH=1 \ > -DCMAKE_BUILD_WITH_INSTALL_RPATH=FALSE \ Just out of curiosity. Does it really work without RPATH? I would bet that there is no way to load Oracle instantClient libs without having RPATH compiled in libtrotl.so > -DENABLE_DB2=0 \ > -DENABLE_TERADATA=0 \ > -DWANT_RPM=0 \ > -DUSE_EXPERIMENTAL=1 \ > .. > > Personally I'm not sure if eg. "er schema" tool is in release-ready > state. It seems unfinished now. Yes it is. I'm really looking forward the moment when core part are stabilized and I will continue working on new features. These will be excluded when having USE_EXPARIMENTAL=0 > On the other side - I use tora3 from trunk almost daily (linux) and it > basically works. > The public testing seems legit. > > > I see some warnings about trotl: > [ 101s] tora.x86_64: W: shlib-policy-missing-suffix > [ 101s] Your package containing shared libraries does not end in a > digit and should > [ 101s] probably be split. > > Ivan, do you plan to release trotl as a standalone library? I will pack > it as a standalone lib if you plan to do it. > > What about libporacle - what do you think about a separate package for > it? tora-oracle for example? Just thinking out loud. So far I do not have any plans with this library. I would leave it as it is now. I do not know any policies for 3rd party libs in distributions. It would be silly to build "Tool for Oracle" without Oracle support. But maybe we will have to provide Oracle connector plugin as a separate package if this will be requested by maintainers. I had to change the copyright notice in all the sources. The physical posting address for GNU foundation was outdated. Fedora looks very strict and I'm afraid Debian will be even "worse". Offtopic: Yesterday I noticed that we have several bugreports on SF discussion forums. But without any responses. What if way dropped/disabled them? I personally only read and respond to a maillist. In case of discussions, nobody gets noticed when a new bugreport is created. Ivan ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |