Melas v0.11.0 release

Melas is an uncomplicated build and packaging tool used to compile software and create installable package files. Melas can be used to reliably reproduce builds and perform dependency tracking. Cross-compilation is supported through integration with Sbox2.

Melas v0.11.0, as released today, adds numerous small and large features. Most notably, the build system autodetection and autoconfiguration has been greatly improved (and Melas can now build most standard software packages without any further configuration). Detailed list of notable changes follows:

  • Renamed the main command mls-build to mls
  • Ability to provide MLS_SPECPATH to look for .mls files in several locations
  • Ability to guess version number based on package url
  • Ability to guess package name based on package url
  • Ability to build URLs without mls spec (fully autodetected build)
  • More flexible mls-prepare to replace mls-extract
  • Greatly enhanced automatic configuration of builds (based on source package contents, try to automatically build it in a suitable way) - automated build support for standard Makefile, GNU autotools and python -type packages.
  • Automatically detect if -dev, -doc, and -locale-* files exist and create appropriate deb packages
  • Ability to automatically create separate locale packages per locale
  • Ability to embed build.mls file in a source tarball and automatically use it for build configuration
  • Removed GCC dependency in Melas
  • “List all” and “Build all” features added (to list/build all available packages)
  • Added numerous hooks to override in mls files to provide greater flexibility
  • Re-designed dependency handling that works much faster especially on a very large number of dependent packages
  • Full integration of Scratchbox2 within Melas
  • “Vacuum builds” for cross-builds that generate a target root filesystem on the fly based on package dependencies, prior to executing the build (allows to compile against a set of pre-compiled packages).

In this version, Melas now becomes quite a powerful tool. Although Melas is heavily used to build the Igelle operating system, it is in no way tied to Igelle, but provides powerful compilation features for other Linux distributions as well. Perhaps one of the most exciting features comes as a result of the autodetection features above, which allows one to build source tarballs into deb files automatically. For example, to downlod, build and package the latest (as of this writing) version of wine:

mls --url=http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.1.8.tar.bz2 rebuild

And you should get a nice wine_1.1.8_i386.deb (with -dev and -doc packages as well) that you can then install with your favourite deb-based package manager.

Or to compile and make a deb package of Python3:

mls --set-name=python3 --set-MLS_CONFIG_PREFIX=/opt/python3 \
--url=http://www.python.org/ftp/python/3.0/Python-3.0rc2.tar.bz2 rebuild

..and you will end up with a nice python3_3.0rc2_i386.deb that you can then install.

(NOTE: Obviously this assumes that you already have the necessary development tools installed, like gcc, make, etc., as well as any necessary development headers and libraries suited for your system.)

Melas v0.11.0 is available for download at the Melas project page. All comments, suggestions and bug reports are most highly welcomed.

Best regards to all and happy compiling :)

3 Responses to “Melas v0.11.0 release”

  1. Hi. I’m trying to build up Igelle for neo freerunner from scratch. I have melas (from svn trunk), melas-tools, armv4t-unknown-linux-gnueabi-gcc built with melas and now I am trying to build ‘bash’ package from Igelle trunk sources. ‘libc’ package was build without any bigger problem, but here I got something strange:
    http://pastebin.com/f17b9c0da . As far as I can see the problem is qemu: http://pastebin.com/f1462bf17 (the a.out works on freerunner). Can you point me for the solution?

  2. Ok.. I got to use qemu-arm-eabi (from http://qemu-arm-eabi.wiki.sourceforge.net/). After that it says that it can’t find /lib/ld-linux.so.3 file, after that it says something about libc.so.6 file. A workaround for it is to copy ld-linux.so.3 file to /lib/ and append: ‘–set-LD_LIBRARY_PATH=/home/hiciu/igelle-build/tools/melas/gcc-armv4t-unknown-linux-gnueabi/sysroot-armv4t-unknown-linux-gnueabi/lib’ to mls command, so it looks like this:
    $ mls –import=../Kod/igelle-trunk/src/base/bash.mls –target=armv4t-unknown-linux-gnueabi –set-LD_LIBRARY_PATH=/home/hiciu/igelle-build/tools/melas/gcc-armv4t-unknown-linux-gnueabi/sysroot-armv4t-unknown-linux-gnueabi/lib configure
    Now I’m compiling in this way coreutils. So far it works.
    I wonder if there is any way to force melas to use ‘/usr/melas/’ dir instead of compiling melas-tools to ‘`pwd`/tools’ on every time when I change workdir..

  3. Great to hear the qemu-arm-eabi works.. Haven’t gotten that far to test on that myself yet :) Would you by any chance have a patch for melas-tools.mls that applies the relevant changes? Anyway, such settings with LD_LIBRARY_PATH should not be necessary, and that would be considered a bug if such is really required to make it work. Which actual version of qemu was this? — And did it have the -drop-ld-preload support already included?

    As for the pwd/tools issue, I agree that it is currently too non-flexible for what it should be. Perhaps there could be an environment variable that, if set, could override the pwd/tools prefix — perhaps this would be simple to implement, although hopefully have no severe consequences. Anyway, in the current Igelle trunk, the only location that deals with this would be in igelle-common.mls (igelle_target_tools_prepare and rebuild -functions). Again, feel free to send a patch if ever you hack in something that works :)

Leave a Comment




Kindly post your comments in english. Due to the international nature of this site, it will be difficult for us if comments are posted in different languages. Thank you very much and thank you for your comments.