Adding codesynthesis odb

[Roflincopter]

I have 2 questions about adding ODB to mxe.

1. Licencing: it defaults to GPL license, but also offers some different licenses like CPL and FPL. So my first question would it be acceptable to add ODB to mxe, I'm currently using it for my project, basically to see of ORM in c++ is something worth doing. And would love to contribute the .mks I have lying around for these libraries.
2. Odb is made up of 3 parts. A base library, A database specific library that depends on the general library and implements a backend database system like sqlite, or mysql. And a third component. The ODB compiler, which runs natively on the system at compile time and is not needed at runtime. It processes some #pragmas and outputs some input files for the normal c++ compiler. The problem is how would one incorporate the ODB compiler in MXE, it is a native application that cannot be built from source and should be installed in "$(MXE_ROOT)/usr/bin/". Or off course installed on the host system.

I don't know if there is a way to make a mxe package that installs a binary in "$(MXE_ROOT)/usr/bin/", which would have my preference. And installing it on the host might work but that makes it less user friendly when using it in the MXE context. Because you need to know that you need to install a separate package on the host system when you want to use ODB.

Kind regards,
Dennis

[TimothyGu]

License-wise, it's fine since it's GPL.

it is a native application that cannot be built from source

err… how would one acquire that then?

I don't know if there is a way to make a mxe package that installs a binary in "$(MXE_ROOT)/usr/bin/", which would have my preference.

Yes there is. Is this ODB compiler target-dependent? In other words, will I need one ODB compiler for 32-bit and one for 64-bit, or does one work for all?

[Roflincopter]

The compiler "package" (see the download page) is just a archive with a precompiled odb compiler called "odb". WIth some configuration files and support libraries in the usual linux filesystem paths /usr /etc/ etc... It only needs to be able to run on the host. So thats why it's so weird. If you are compiling for i686-w64-mingw32 and x86_64-w64-mingw32 on a x86_64 machine, you would only need the x86_64 odb binary for your host. It just converts #pramas in code to source files which are then compiled by your target compiler. (which you somehow define in your buildsystem, I made some cmake files to do this, but this could be done manually aswell)

So like I said you could install the odb compiler on your host system, that works. But it kinda feels wrong, so I want to somehow include it in the mxe system.

[TimothyGu]

That page says:

The ODB compiler is distributed in source code as well as pre-compiled binary packages for a number of platforms.

Being a port-like system, we always prefer building from source code.

If you are compiling for i686-w64-mingw32 and x86_64-w64-mingw32 on a x86_64 machine, you would only need the x86_64 odb binary for your host.

Ah cool. Yes, you can make odb compiler a "native package" that is only built once for all targets. Add

$(PKG)_TARGETS  := $(BUILD)

and in the $(PKG)_BUILD macro set the installation prefix to $(PREFIX).

@tonytheodore and @starius should be able to help you more with creating native packages.

[Roflincopter]

Right, missed that. Test building it now to see if there are any pitfalls. It seems it only has libcutl as dependency which should also become a "native package" then. But I'll complete the odb build and test the resulting binary to make sure everything is working.

Edit:
Tested the built binary by giving it input and comparing the output with output I've gotten with the odb compiler found in the arch repositories (same version). It generates the same output. So building odb is as simple als having libcutl installed and running ./configure and make.

So I'll just wait for some more info on "native packages" especially if it is ok to add these to MXE.

[Roflincopter]

So I was trying to create the libcutl and odb native packages today, but I ran into an issue. The 2 .mk's I created:

libcutl.mk

# This file is part of MXE.
# See index.html for further information.

PKG             := libcutl
$(PKG)_IGNORE   :=
$(PKG)_VERSION  := 1.10.0
$(PKG)_SHORTV   := 1.10
$(PKG)_CHECKSUM := 125163c670e372b47d5626d54379ff8fbaded6ccd5db77ac0bf5912a4017121c
$(PKG)_SUBDIR   := $(PKG)-$($(PKG)_VERSION)
$(PKG)_FILE     := $(PKG)-$($(PKG)_VERSION).tar.bz2
$(PKG)_URL      := http://www.codesynthesis.com/download/libcutl/$($(PKG)_SHORTV)/$($(PKG)_FILE)
$(PKG)_DEPS     :=
$(PKG)_TARGETS  := $(BUILD)

define $(PKG)_BUILD
    cd '$(1)' && ./configure \
        $(MXE_CONFIGURE_OPTS) \
        --disable-debug
    $(MAKE) -C '$(1)' -j '$(JOBS)' install
endef

libodb.mk

# This file is part of MXE.
# See index.html for further information.

PKG             := odb
$(PKG)_IGNORE   :=
$(PKG)_VERSION  := 2.4.0
$(PKG)_SHORTV   := 2.4
$(PKG)_CHECKSUM := 6785154fa98ea3977c8c2ab38cec16c4aa78c2c2039e80cd2908347b1c1d4198
$(PKG)_SUBDIR   := $(PKG)-$($(PKG)_VERSION)
$(PKG)_FILE     := $(PKG)-$($(PKG)_VERSION).tar.bz2
$(PKG)_URL      := http://www.codesynthesis.com/download/odb/$($(PKG)_SHORTV)/$($(PKG)_FILE)
$(PKG)_DEPS     := libcutl
$(PKG)_TARGETS  := $(BUILD)

define $(PKG)_BUILD
    echo $(MXE_CONFIGURE_OPTS)
    echo $(PREFIX)
    cd '$(1)' && ./configure \
        $(MXE_CONFIGURE_OPTS) \
        --disable-debug
    $(MAKE) -C '$(1)' -j '$(JOBS)' install
endef

The problem is that odb package also needs the gcc plugin development headers. These are installed on my system, but because of the prefix, set by the $(MXE_CONFIGURE_OPTS) (which is $(MXE_ROOT)/usr/x86_64-unknown-linux-gnu in my case), the development headers are not found. I don't really have any ideas how to solve this issue.

EDIT:
So with help of this mail thread. I am able to build odb with the following .mk.

# This file is part of MXE.
# See index.html for further information.

PKG             := odb
$(PKG)_IGNORE   :=
$(PKG)_VERSION  := 2.4.0
$(PKG)_SHORTV   := 2.4
$(PKG)_CHECKSUM := 6785154fa98ea3977c8c2ab38cec16c4aa78c2c2039e80cd2908347b1c1d4198
$(PKG)_SUBDIR   := $(PKG)-$($(PKG)_VERSION)
$(PKG)_FILE     := $(PKG)-$($(PKG)_VERSION).tar.bz2
$(PKG)_URL      := http://www.codesynthesis.com/download/odb/$($(PKG)_SHORTV)/$($(PKG)_FILE)
$(PKG)_DEPS     := libcutl
$(PKG)_TARGETS  := $(BUILD)

define $(PKG)_BUILD
    cd '$(1)' && CPPFLAGS="-I$(SHELL $(BUILD_CXX) --print-file-name=plugin)/include -I$(PREFIX)/$(BUILD)/include" LDFLAGS="-L$(PREFIX)/$(BUILD)/lib" ./configure \
        $(MXE_CONFIGURE_OPTS) \
        --disable-debug \
        --disable-static \
        --enable-shared
    $(MAKE) -C '$(1)' -j '$(JOBS)' install
endef

Which raises some questions. Is this acceptable / am I doing some thing wrong in the first place that I have to set these CPPFLAGS and LDFLAGS.

This also depends in hard way on gcc, which is obvious if you know the project and take into account it uses a gcc plugin. But I also notice that there are some efforts to support clang in MXE. Then this build script would fail. But there is no reason that you could not build all the software with the clang compiler but still have the gcc dependent odb compiler. but then I should somehow specify it depends on gcc which I currently cannot do (adding it to depends won't work because gcc won't be build for X86_64-unknown-linux-gnu as it uses the native one). But these are just some thoughts.

[tonytheodore]

Is this acceptable / am I doing some thing wrong in the first place that I have to set these CPPFLAGS and LDFLAGS.

I can't see anything wrong with that, the native gcc needs to know where to search - some ./configure scripts will add --prefix but I don't know how common that is.

This also depends in hard way on gcc ... some efforts to support clang in MXE

Not sure how best to handle this, future support for clang is as a cross-compiler, native clang support is already present (say OSX). Most likely we'd have to (conditionally?) build a native gcc that could be added to deps.