Official Debian package

alexmyczko commented 4 months ago

There's the intent to package at https://bugs.debian.org/897673 and the current public state: https://salsa.debian.org/science-team/coot and then there's some success on a local machine that builds 1.1.07 and if software builds successfully, it's likely to also work and be packagable... (Using this place to keep track of the history of building the package)

correction: almost success

[100%] Linking CXX executable test-molecules-container
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libssm.so: undefined reference to `mmdb::Atom::Transform(double (&) [4][4])'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libssm.so: undefined reference to `mmdb::Mat4Copy(double (&) [4][4], double (&) [4][4])'
collect2: error: ld returned 1 exit status

Just to see where we are: https://repology.org/project/coot/versions (comparisons are bad, Paul Watzlawik, Situation is Hopeless, But Not Serious, The Pursuit of Unhappiness)

pemsley commented 3 months ago

Hello @alexmyczko. I was unware of this effort - or had forgotten about it. I would like this to be a thing and am happy to put some hours in to help make it happen. I have seen the linking error you mention above some years ago. I don't recall at the moment how to fix it. I will have a look and a think.

So, it looks like you are using CMake to build the project. Is that the case? The CMake system (at the moment only) builds up to libcootapi and chapi (the nanobind-based python coot_headless_api). To build the Coot binary and Layla you will need to use configure (at the moment). You may find build-it-3-3 useful. Which version of mmdb (and clipper) are you using/linking against? What does CMakeCache.txt say about MMDB? Can you compile with VERBOSE=1 ?

alexmyczko commented 3 months ago

waiting for https://bugs.debian.org/1064953

pemsley commented 3 months ago

Interesting news.

which is due to be installed in the Debian FTP archive

What is the timescale for this? Hours or months?

Yes, RDKit is now a hard dependency.

With the move to GTK4 (in Coot 1.1) the dependency on a canvas has been removed.

Is there a way to check for lack of copyright assignment?

alexmyczko commented 3 months ago

It was like sub-hour, package already fixed in sid, webpage outdated, i got it from incoming.debian.org and building to test... thanks for clarifying it is a hard dependency.

I usually postpone the really hard things like debian/copyright. first it builds, then it works, and so on...

BUT let me assure you, there's interest from many sides, and I am now equipped with a new vortex m0110 keyboard which encourages me to type alot ;)

pemsley commented 3 months ago

OK, sounds good. What's next/what can I help with?

alexmyczko commented 3 months ago

At the moment nothing, I had problems building rdkit src deb pkg, but now it's built installing it from the archive (sid, amd64) and continuing trying, this is very appreciated your help. No worries, I sure will have questions...

pemsley commented 3 months ago

99% of the problems of installing Coot is installing the dependencies.

Which version of GTK4 are you going to use?

alexmyczko commented 3 months ago

here's the cmake . output

cmake .
CMake Warning (dev) at CMakeLists.txt:2 (project):
  cmake_minimum_required() should be called prior to this top-level project()
  call.  Please see the cmake-commands(7) manual for usage documentation of
  both commands.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Looking for mmdb2/mmdb_defs.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libmmdb2.so  
-- Looking for ssm/ssm_vxedge.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libssm.so  
-- Looking for clipper/clipper.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-core.so  
-- FFTW2 libraries - /usr/lib/libsfftw.so
--                 - /usr/lib/libsrfftw.so
-- FFTW2 header directory - /usr/include
-- Looking for clipper/clipper-mmdb.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-mmdb.so  
-- Looking for clipper/clipper-ccp4.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so  
-- Looking for clipper/clipper-contrib.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-contrib.so  
-- Looking for clipper/clipper-minimol.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-minimol.so  
-- Looking for clipper/clipper-cif.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-cif.so  
-- CCP4 include directory: /usr/include
-- Found gemmi version 0.6.4
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found suitable version "1.83.0", minimum required is "1.83.0")  
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found version "1.83.0") found components: iostreams system python regex thread serialization 
-- Configuring done (0.6s)
-- Generating done (0.5s)
-- Build files have been written to: /var/www/debian/coot/2024/coot-Release-1.1.07

GTK4 looks like:

root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# dpkg -l |grep gtk4
ii  gir1.2-xdpgtk4-1.0:amd64                                    0.7.1-5                                      amd64        Flatpak portal library - introspection data for GTK 4
ii  libportal-gtk4-1:amd64                                      0.7.1-5                                      amd64        Flatpak portal library for GTK 4 GUIs
ii  libportal-gtk4-dev:amd64                                    0.7.1-5                                      amd64        Flatpak portal library (development files for GTK 4)
ii  libvte-2.91-gtk4-0:amd64                                    0.75.91-2                                    amd64        Terminal emulator widget for GTK 4 - runtime files
ii  libvte-2.91-gtk4-dev:amd64                                  0.75.91-2                                    amd64        Terminal emulator widget for GTK 4 - development files
ii  python3-wxgtk4.0                                            4.2.1+dfsg-3                                 amd64        Python 3 interface to the wxWidgets Cross-platform C++ GUI toolkit
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# dpkg -l |grep gtk-4
ii  gir1.2-gtk-4.0:amd64                                        4.12.5+ds-3                                  amd64        GTK graphical user interface library -- gir bindings
ii  gir1.2-javascriptcoregtk-4.0:amd64                          2.42.5-1                                     amd64        JavaScript engine library from WebKitGTK - GObject introspection data
ii  gir1.2-javascriptcoregtk-4.1:amd64                          2.42.5-1                                     amd64        JavaScript engine library from WebKitGTK - GObject introspection data
ii  libgtk-4-1:amd64                                            4.12.5+ds-3                                  amd64        GTK graphical user interface library
ii  libgtk-4-bin                                                4.12.5+ds-3                                  amd64        programs for the GTK graphical user interface library
ii  libgtk-4-common                                             4.12.5+ds-3                                  all          common files for the GTK graphical user interface library
ii  libgtk-4-dev:amd64                                          4.12.5+ds-3                                  amd64        development files for the GTK library
ii  libgtk-4-media-gstreamer                                    4.12.5+ds-3                                  amd64        GStreamer media backend for the GTK graphical user interface library
ii  libjavascriptcoregtk-4.0-18:amd64                           2.42.5-1                                     amd64        JavaScript engine library from WebKitGTK
ii  libjavascriptcoregtk-4.0-dev:amd64                          2.42.5-1                                     amd64        JavaScript engine library from WebKitGTK - development files
ii  libjavascriptcoregtk-4.1-0:amd64                            2.42.5-1                                     amd64        JavaScript engine library from WebKitGTK
ii  libjavascriptcoregtk-4.1-dev:amd64                          2.42.5-1                                     amd64        JavaScript engine library from WebKitGTK - development files
ii  libswt-gtk-4-java                                           4.26.0-2                                     amd64        Standard Widget Toolkit for GTK+ Java library
ii  libswt-gtk-4-jni                                            4.26.0-2                                     amd64        Standard Widget Toolkit for GTK+ JNI library
ii  libwebkit2gtk-4.0-37:amd64                                  2.42.5-1                                     amd64        Web content engine library for GTK
ii  libwebkit2gtk-4.0-dev:amd64                                 2.42.5-1                                     amd64        Web content engine library for GTK - development files
ii  libwebkit2gtk-4.1-0:amd64                                   2.42.5-1                                     amd64        Web content engine library for GTK
ii  libwebkit2gtk-4.1-dev:amd64                                 2.42.5-1                                     amd64        Web content engine library for GTK - development files

pemsley commented 3 months ago

I have lead you astray, it seems.

The CMake build system builds (only) libcootapi and chapi - which are fine things to have but they are not coot.

Use configure to build coot. Read build-it-3-3 to see how I use coot's configure

alexmyczko commented 3 months ago

so i'll need configure AND cmake, or configure also builds libcootapi/chapi?

pemsley commented 3 months ago

so i'll need configure AND cmake, or configure also builds libcootapi/chapi?

Ask me that now and I will say "Yes, both." They should build different libraries and not step on each other's toes.

This answer may change in the future as I get to like and understand CMake more.

You will also build Layla - which is a useful stand-alone chemisry application.

alexmyczko commented 3 months ago

that's fine, i've seen projects that have much worse build systems or well lacking them completey :)

pemsley commented 3 months ago

FWIW, libcootapi is the core library behind Moorhen (https://moorhen.org)

https://github.com/moorhen-coot/Moorhen

alexmyczko commented 3 months ago

ok the cmake part looks good

[100%] Linking CXX executable test-molecules-container
/usr/bin/cmake -E cmake_link_script CMakeFiles/test-molecules-container.dir/link.txt --verbose=1
/usr/bin/c++ -O3 -DNDEBUG "CMakeFiles/test-molecules-container.dir/api/test_molecules_container.cc.o" "CMakeFiles/test-molecules-container.dir/api/filo-tests.cc.o" -o test-molecules-container  -Wl,-rpath,/var/www/debian/coot/2024/coot-Release-1.1.07 libcootapi.so /usr/lib/x86_64-linux-gnu/libssm.so /usr/lib/x86_64-linux-gnu/libclipper-minimol.so /usr/lib/x86_64-linux-gnu/libclipper-mmdb.so /usr/lib/x86_64-linux-gnu/libclipper-cif.so /usr/lib/x86_64-linux-gnu/libclipper-core.so /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so /usr/lib/x86_64-linux-gnu/libclipper-contrib.so /usr/lib/libsfftw.so /usr/lib/libsrfftw.so /usr/lib/x86_64-linux-gnu/libmmdb2.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libgsl.so /usr/lib/x86_64-linux-gnu/libgslcblas.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.83.0 
make[2]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07'
[100%] Built target test-molecules-container
make[1]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07'
/usr/bin/cmake -E cmake_progress_start /var/www/debian/coot/2024/coot-Release-1.1.07/CMakeFiles 0

so on to configure, aha no configure, let me guess which parts of this i need (witout reading the manual)

libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure

i have a note about autoreconf -vif but i don't remember why...

alexmyczko commented 3 months ago

root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: linking file 'macros/libtool.m4'
libtoolize: linking file 'macros/ltoptions.m4'
libtoolize: linking file 'macros/ltsugar.m4'
libtoolize: linking file 'macros/ltversion.m4'
libtoolize: linking file 'macros/lt~obsolete.m4'
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# aclocal
configure.ac:35: warning: macro 'AM_ACLOCAL_INCLUDE' not found in library
configure.ac:112: warning: macro 'AM_MINGW_WINDOWS' not found in library
configure.ac:115: warning: macro 'AM_PATH_GLOB' not found in library
configure.ac:133: warning: macro 'AM_PATH_SQLITE3' not found in library
configure.ac:184: warning: macro 'AM_PATH_MMDB2' not found in library
configure.ac:186: warning: macro 'AM_WITH_SSM' not found in library
configure.ac:191: warning: macro 'AM_SINGLE_FFTW2' not found in library
configure.ac:195: warning: macro 'AM_PATH_CLIPPER' not found in library
configure.ac:411: warning: macro 'AM_COOT_SYS_BUILD_TYPE' not found in library
configure.ac:433: warning: macro 'AM_WITH_MYSQL_DATABASE' not found in library
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# autoheader
autoheader: warning: WARNING: Using auxiliary files such as 'acconfig.h', 'config.h.bot'
autoheader: WARNING: and 'config.h.top', to define templates for 'config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader: 
autoheader: WARNING: Using the third argument of 'AC_DEFINE_UNQUOTED' and
autoheader: WARNING: 'AC_DEFINE' allows one to define a template without
autoheader: WARNING: 'acconfig.h':
autoheader: 
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader:         [Define if a function 'main' is needed.])
autoheader: 
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
autoheader: error: error: AC_CONFIG_HEADERS not found in configure.ac
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# automake --force-missing --add-missing
configure.ac:42: installing './compile'
configure.ac:32: installing './missing'
MoleculesToTriangles/CXXClasses/Makefile.am: installing './depcomp'
api/Makefile.am:89: installing './py-compile'
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# autoconf                              
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking whether make supports the include directive... yes (GNU style)
checking dependency style of g++... gcc3
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking which libtool initialization strategy to adopt... AC-PROG-LIBTOOL
checking what warning flags to pass to the C compiler... -Wall -Wunused
checking what language compliance flags to pass to the C compiler... 
checking what warning flags to pass to the C++ compiler... -Wall -Wno-unused
checking what language compliance flags to pass to the C++ compiler... 
checking for sys/stdtypes.h... no
checking for OpenMP flag of C compiler... -fopenmp
checking whether g++ supports C++11 features by default... yes
checking for std::thread in thread... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for glib-2.0... yes
checking if this is MINGW on Windows... no
checking if this is msys2 windows 64... no
checking for libpng >= 1.2... yes
checking for cairo >= 1.14... yes
checking for SQLite3... yes
checking for mmdb2... yes
checking for ssm... yes
checking for non-prefixed single-precision FFTW2 (fftw.h)... no
yes
checking for Clipper... yes
checking for gsl-config... /usr/bin/gsl-config
checking for GSL - version >= 1.3... yes
checking for glm >= 0.9.9... yes
checking for gtk4 >= 4.4... yes
checking for epoxy >= 1.5... yes
checking for a Python interpreter with version >= 3.7... python3
checking for python3... /usr/bin/python3
checking for python3 version... 3.11
checking for python3 platform... linux
checking for python3 script directory... ${prefix}/lib/python3/dist-packages
checking for python3 extension module directory... ${exec_prefix}/lib/python3/dist-packages
checking for python3.11... (cached) /usr/bin/python3
checking for a version of Python >= '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/usr/include/python3.11
checking for Python library path... -L/usr/lib/x86_64-linux-gnu -lpython3.11
checking for Python site-packages path... /usr/lib/python3/dist-packages
checking python extra libraries... -ldl -lm
checking python extra linking flags... -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
checking consistency of all components of python development environment... yes
checking python3 module: requests... yes
checking for pygobject-3.0 >= 3.36... yes
checking for boostlib >=  (102000)... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Python library is available... yes
checking whether boost_python is the correct library... no
checking whether boost_python311 is the correct library... yes
checking for RDKit in NONE
Configuration error. No, bad... we do not have necessary RDKIT

pemsley commented 3 months ago

aclocal -I macros

You can take a look at autogen.sh - that was written presuming that the dependencies are installed in the user's directories (by the build script). You are at about line 4544 of the build-it-3-3

If you prefer, you can build from a tarball release:

https://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/source/releases/coot-1.1.07.tar.gz

alexmyczko commented 3 months ago

i do have the tarball release (ah but selfmade git checkout without configure, now i get it), i guess i'll help it find rdkit:

# grep -i rdkit configure
RDKIT_LIBS
RDKIT_CXXFLAGS
with_rdkit_prefix
  --with-rdkit-prefix location of the RDKit package
# Boost-Python is needed for RDKit interface.
# Check whether --with-rdkit-prefix was given.
if test ${with_rdkit_prefix+y}
  withval=$with_rdkit_prefix; rdkit_prefix="$withval"
  rdkit_prefix=false
if test x$rdkit_prefix = xfalse ; then
   echo checking for RDKit in $prefix
   if test -x $prefix/include/rdkit ; then
      echo OK, good we found RDKit in $prefix
      rdkit_install_dir=$prefix
      RDKIT_CXXFLAGS="-I$rdkit_install_dir/include/rdkit -DRDKIT_HAS_CAIRO_SUPPORT"
      RDKIT_LIBS="-L$rdkit_install_dir/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitcoordgen -lRDKitMolChemicalFeatures -lRDKitPartialCharges -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitRingDecomposerLib -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -l$BOOST_PYTHON_LIB $pl"
      echo Configuration error. No, bad... we do not have necessary RDKIT
   rdkit_install_dir="$withval"
   # better RDKit linking I hope
   RDKIT_CXXFLAGS="-I$rdkit_install_dir/include/rdkit -DRDKIT_HAS_CAIRO_SUPPORT"
   RDKIT_LIBS="-L$rdkit_install_dir/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitcoordgen -lRDKitMolChemicalFeatures -lRDKitPartialCharges -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitRingDecomposerLib -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -l$BOOST_PYTHON_LIB $pl"

configure was successfull with just --with-rdkit-prefix= so waiting for make

pemsley commented 3 months ago

--with-rdkit-prefix=$install_top_dir where $install_top_dir is /usr I guess

alexmyczko commented 3 months ago

/usr/bin/ld: cannot find -lRDKitcoordgen: No such file or directory
/usr/bin/ld: cannot find -lRDKitRingDecomposerLib: No such file or directory

hm they don't come with

$ dpkg -L librdkit1
<alot>
$ dpkg -L librdkit1|grep RDKitcoordgen
$ dpkg -L librdkit1|grep RDKitRingDec
<allempty>

Looking into https://salsa.debian.org/debichem-team/rdkit/-/blob/master/debian/rules?ref_type=heads

pemsley commented 3 months ago

Coordgen is a Schrödinger library. https://github.com/schrodinger/coordgenlibs I guess if it is not installed then the RDKit can't make a wrapper library. You could try removing RDKitcoordgen and RDKitRingDecomposerLib from configure.ac Coot doesn't directly use functions from either library.

alexmyczko commented 3 months ago

this would not do it?

sed -i s,-lRDKitcoordgen,,g configure
sed -i s,-lRDKitRingDecomposerLib,,g configure

pemsley commented 3 months ago

I imagine so.

alexmyczko commented 3 months ago

ended with:

libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o  .libs/layla_embedded.o .libs/generators.o .libs/notifier.o .libs/signals.o .libs/state.o .libs/ui.o .libs/utils.o ligand_editor_canvas/.libs/core.o .libs/ligand_editor_canvas.o ligand_editor_canvas/.libs/model.o ligand_editor_canvas/.libs/tools.o ligand_editor_canvas/.libs/render.o .libs/python_utils.o   -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/geometry/.libs -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/lidia-core/.libs -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/utils/.libs ../geometry/.libs/libcoot-geometry.so ../lidia-core/.libs/libcoot-lidia-core.so ../utils/.libs/libcoot-utils.so -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -L/usr/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitMolChemicalFeatures -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -lboost_python311 -L/usr/lib/x86_64-linux-gnu -lpython3.11 -lcurl -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/13 -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/13/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/13/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crtn.o  -g -O2   -Wl,-soname -Wl,libcoot-layla.so.0 -o .libs/libcoot-layla.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libcoot-layla.so.0" && ln -s "libcoot-layla.so.0.0.0" "libcoot-layla.so.0")
libtool: link: (cd ".libs" && rm -f "libcoot-layla.so" && ln -s "libcoot-layla.so.0.0.0" "libcoot-layla.so")
libtool: link: ar cr .libs/libcoot-layla.a  layla_embedded.o generators.o notifier.o signals.o state.o ui.o utils.o ligand_editor_canvas/core.o ligand_editor_canvas.o ligand_editor_canvas/model.o ligand_editor_canvas/tools.o ligand_editor_canvas/render.o python_utils.o
libtool: link: ranlib .libs/libcoot-layla.a
libtool: link: ( cd ".libs" && rm -f "libcoot-layla.la" && ln -s "../libcoot-layla.la" "libcoot-layla.la" )
/bin/bash ../libtool  --tag=CXX   --mode=link g++ -DPKGDATADIR='"/usr/local/share/coot"' -DUSE_SQLITE3   -lcurl -DUSE_LIBPNG=1 -I/usr/include/libpng16  -g -O2 -Wall -Wno-unused  -std=c++17   -o layla main.o libcoot-layla.la ../utils/libcoot-utils.la -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0  -lglib-2.0  
libtool: link: g++ -DPKGDATADIR=\"/usr/local/share/coot\" -DUSE_SQLITE3 -DUSE_LIBPNG=1 -I/usr/include/libpng16 -g -O2 -Wall -Wno-unused -std=c++17 -o .libs/layla main.o  -lcurl ./.libs/libcoot-layla.so ../utils/.libs/libcoot-utils.so -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0
/usr/bin/ld: ./.libs/libcoot-layla.so: undefined reference to `coot::rdkit_mol(coot::dictionary_residue_restraints_t const&)'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:684: layla] Error 1
make[1]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07/layla'
make: *** [Makefile:745: all-recursive] Error 1

need make VERBOSE=1?

pemsley commented 3 months ago

This looks like a source-code bug.

Layla uses rdkit. Check the use of the #define USE_RDKIT - coot::rdkit_mol() should have been added to libcoot-lidia-core and libcoot-lidia-core should have been linked into libcoot-layla.

I have to go to work now - hiatus.

pemsley commented 3 months ago

@hgonomeg do you have thoughts about this?

I thought that the libraries with which a target is linked should be specified on the command line after the target. This seems to specify libcoot-lidia-core.so before -o libcoot-layla.so

pemsley commented 3 months ago

@alexmyczko

What does this say?

nm --demangle lidia-core/.libs/libcoot-lidia-core.so | grep rdkit_mol

merkys commented 3 months ago

Very happy to see this development! I have attempted to build a Debian package for coot some years ago, with varying level of success, but did not follow through the whole process.

I am puzzled to see RDKitcoordgen and RDKitRingDecomposerLib, RDKit does not seem to have them in Debian. Most likely this is due to version difference, Debian has RDKit 202309.3.

I recall I had to patch lbg/Makefile.am to get rid of undefined reference messages:

--- a/lbg/Makefile.am
+++ b/lbg/Makefile.am
@@ -80,7 +80,7 @@
 # (if that is annoying, then remove it and expand it by hand)
 #
 lidia_LDADD = \
-       ./libcoot-lidia.la $(GLOB_LIBS) $(RDKIT_LIBS) $(L_BOOST_PYTHON)
+       ./libcoot-lidia.la ../lidia-core/.libs/libcoot-lidia-core.la $(GLOB_LIBS) $(RDKIT_LIBS) $(MMDB_LIBS) $(GTK_LIBS) $(PYTHON_LIBS) $(L_BOOST_PYTHON)

 # not needed: linked by dependency libs
 # $(CLIPPER_LIBS) $(MMDB_LIBS) $(GSL_LIBS)

alexmyczko commented 3 months ago

@merkys @pemsley waiting for further instructions..

merkys commented 3 months ago

@alexmyczko have you pushed your packaging attempt somewhere? I would like to give it a shot.

alexmyczko commented 3 months ago

@merkys the current stuff is at http://sid.ethz.ch/debian/coot/2024/ and without debian/ it's just building manually from source, once this is successfull, i can start/continue what's on salsa and put it on salsa...

If IRC is easier for you, i'm there as tarzeau (or tarzeau_)

pemsley commented 3 months ago

The lbg directory is just hanging around for historical reasons. It is not compiled. It cannot be compiled with GTK4.

lbg has been replaced by layla.

pemsley commented 3 months ago

@merkys How about doing acedrg after coot? 😃

merkys commented 3 months ago

@alexmyczko

@merkys the current stuff is at http://sid.ethz.ch/debian/coot/2024/ and without debian/ it's just building manually from source, once this is successfull, i can start/continue what's on salsa and put it on salsa...

If IRC is easier for you, i'm there as tarzeau (or tarzeau_)

Thanks. It would be nice to have debian/ directory as soon as possible, as dependency collection alone took quite some time for me. Nevertheless, I managed to call cmake successfully, but configure still complains about:

checking for RDKit in NONE
Configuration error. No, bad... we do not have necessary RDKIT

I have removed RDKitcoordgen and RDKitRingDecomposerLib, but possibly some other modules could not be found as well.

I will continue my attempts next week. We may coordinate on IRC, that is an option.

@pemsley

@merkys How about doing acedrg after coot? 😃

Definitely! 😃

pemsley commented 3 months ago

Re: Configuration error. No, bad... we do not have necessary RDKIT

If you specify --with-rdkit-prefix=<something> then you will not get this error message.

merkys commented 3 months ago

If you specify --with-rdkit-prefix=<something> then you will not get this error message.

Indeed, this worked for me as --with-rdkit-prefix=/usr as RDKit libraries are under /usr/lib/ and headers at /usr/include/rdkit/. Nevertheless I ran into the same problem as @alexmyczko:

/usr/bin/ld: ./.libs/libcoot-layla.so: undefined reference to `coot::rdkit_mol(coot::dictionary_residue_restraints_t const&)'

libcoot-lidia-core.so does not seem to mention rdkit_mol (nm --demangle lidia-core/.libs/libcoot-lidia-core.so | grep rdkit_mol returns no output)

pemsley commented 3 months ago

Hmm... See the build-it-3-3 script.

Are you passing --with-enhanced-ligand-tools to configure?

merkys commented 3 months ago

@pemsley

Are you passing --with-enhanced-ligand-tools to configure?

Success! I apparently missed this thinking that it may not affect the overall linking that much.

@alexmyczko I will start preparing debian/ directory ASAP.

The next major task will be the copyright review. I am aware coot is dedicated to free software which I greatly admire. However, we have to show that all files bearing "All rights reserved" or "Copyright" have explicit license pointer. We need to make sure there are no files with dubious licenses.

alexmyczko commented 3 months ago

are you using sbuild and decopy?

merkys commented 3 months ago

are you using sbuild and decopy?

I am using sbuild. I was not aware of decopy, but I have been using licensecheck - I will give decopy a look.

pemsley commented 3 months ago

I apparently missed this thinking that it may not affect the overall linking that much.

ENHANCED_LIGAND_TOOLS should go hand-in-hand with RDKit usage, but I don't test configure without --enhanced-ligand-tools so I missed that case.

pemsley commented 3 months ago

I ran decopy and I didn't know what to make of the results.

I thought the fact that it picked up a scheme lambda function a copyright was funny:

(lambda (c) (is-solvent-chain? imol c))

alexmyczko commented 3 months ago

i guess that is a false result, skip/ignore, i have found it very useful to skim through its result to make sure to not forget something obvious...

pemsley commented 3 months ago

This is what I got. What do I do now?

decopy.log

alexmyczko commented 3 months ago

https://salsa.debian.org/science-team/coot put your packaging here, and I'll try to process it with a result, explaining to you what I did and how I did... ?

merkys commented 3 months ago

@pemsley

I ran decopy and I didn't know what to make of the results.

I thought the fact that it picked up a scheme lambda function a copyright was funny:

(lambda (c) (is-solvent-chain? imol c))

None of the tools for copyright review is ideal, alas. What you got from decopy is a scaffold for debian/copyright file. It looks rather raw now, but it is a good starting point. I would look at files identified by decopy as lacking explicit license statement, also ones which may caused unusual output by decopy.

What might not get past Debian copyright audit immediately are files under MoleculesToTriangles/, buccaneer_ml_growing/, cootilus/, cootaneer/ and surface/ as they bear "all rights reserved" notice without explicitly mentioning the license. Kevin Cowtan told me personally that Nautilus subset used by coot is licensed under LGPL, but this may not get past the copyright audit as this knowledge both not included in coot's source and was communicated in personal correspondence.

@alexmyczko

https://salsa.debian.org/science-team/coot put your packaging here, and I'll try to process it with a result, explaining to you what I did and how I did... ?

Good idea, this is exactly what I am going to do.

pemsley commented 3 months ago

MoleculesToTriangles/, buccaneer_ml_growing/, cootilus/, cootaneer/ and surface

Ha. All code not written by me.

pemsley commented 3 months ago

I am going to delete surface right now.

pemsley commented 3 months ago

I have not found cootlius or cootaneer to be useful and I don't teach them. I am not sure that they are even available in the new GTK4 interface. They can be removed if they prove to be problematic.

I now notice that I need to replace some code in MoleculesToTriangles - that might take a few days.

merkys commented 3 months ago

@alexmyczko I have pushed my packaging attempts to https://salsa.debian.org/science-team/coot. I re-used debian/ directory from earlier attempts (5 years ago?), but updating the dependency list and building routines (configure part). Feel free to modify.

I am having troubles with setting sbuild on a more effective build machine due to ongoing t64 and usrmerge transitions. On the other hand, this will divert my attention to debian/copyright :smile:

@pemsley thanks a lot for clarifying cootlius, cootaneer and surface. Just FYI, you do not have to remove them from coot - we can exclude files/directories on Debian side, the only thing that matters is that the package builds without them.

alexmyczko commented 3 months ago

@merkys same, dpkg-checkbuilddeps: error: Unmet build dependencies: libgtkmm-4.0-dev.. maybe tomorrow...

pemsley / coot

Official Debian package #120