Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-24

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:35 jeffreykegler joined #marpa
01:36 jeffreykegler While I was away from the channel people said such nice things about me, I'm reluctant to come back. :-)
01:45 shadowpaste "jeffreykegler" at 99.107.98.155 pasted "marpa.def file -- first cut" (211 lines) at http://scsys.co.uk:8002/356177
01:45 jeffreykegler jdurand: as my good friend shadowpaste has just said, I've pasted a copy of my first cut at auto-generation of the marpa.def file.
01:45 jeffreykegler With the Github issue are details of the commit, and my comments on the choices I made.
01:47 jeffreykegler jdurand: But the commit itself did not include an actual marpa.def, because it's not a source file, and therefore not managed by git.  The paste will give you a sample marpa.def to work with, in case auto-generating it doesn't work or is not convenient.
04:52 jdurand joined #marpa
04:53 jdurand Re http://irclog.perlgeek.de/marpa/2014-04-22#i_8621962 - debian packages updated, resource: "deb http://jeandamiendurand.free.fr/debian/marpa unstable contrib"
16:54 jeffreykegler joined #marpa
17:53 jdurand joined #marpa
17:55 jdurand Jeffrey, each time you release a new libmarpa you will increment which numbers between major, minor and micro versions
17:55 jdurand ?
17:56 jeffreykegler Mostly the micro number for development releases.
17:56 jeffreykegler I adopted the system of building version # into the name, apparently used a lot in Linux, and recommended for my type of situation by the autoconf folks.
17:57 jdurand Ok, e.g. 6.0.1 and 6.0.2 a compatible from API point of view
17:58 jeffreykegler Because the # is built into the name, 6.0.1 and 6.0.2 should be treated as *NOT* compatible.
17:58 jeffreykegler To move to a new version, you'll have to re-link.
17:59 jdurand Hmm... I have trouble with this model. This will be OK on Linux/Unix because the SONAME writen into the shared library headers can contain a number like x.y.z
17:59 jdurand but on Windows, only the notion the major.minor exist
18:00 jdurand That is: from a pure binary point of view, taking 6.0.1 and 6.0.2 will produce libraries that have "image version" (that's how they call it) "6.00" and "6.00"
18:00 jdurand C.f. http://msdn.microsoft.com/en-us/library/h88b7dc8.aspx
18:01 jdurand I'll need advice from other Win32 users, but it seems to me your model is not enough. You see, a shared library can have any name. What is used in the version on the library headers
18:01 jeffreykegler How does libtool deal with this situation?
18:02 jdurand "is not enough" == "does not work on all platforms" I meant
18:02 jdurand let me do a vanilla configure on Marpa distribution
18:02 jdurand few seconds
18:03 * jdurand is downloading Marpa-R2-2.085_003.tar.gz -;
18:06 jdurand Yes, "objdump -x libmarpa-6.0.2.so | grep -i soname" gives: libmarpa-6.0.2.so
18:06 jdurand i.e. the soname is the whole name of the library
18:06 jdurand I do not know if this work with Win32
18:08 jdurand afk for a while
18:08 jeffreykegler The 3-component standard is very, very standard, and my tool chain situation between Module::Build and autoconf is very tricky.
18:08 jeffreykegler I'll keep going -- you can backlog to catch up.
18:09 jdurand http://stackoverflow.com/questions/20349910/how-to-define-shared-library-major-version-in-autoconf
18:12 jeffreykegler I imagine Linux-world libraries using the X.Y.Z scheme are used in Win32 all the time, so there must be solutions out there.
18:16 jeffreykegler One thing that seems to be common is simply to translate version numbers more or less completely, so that their is little or no relationship between them.  This you have a Libmarpa version and a Windows shared library version, different, and using different systems.  This sort of thing seems to be the norm.And it does have the advantage that if you change the
18:18 jeffreykegler And it does have the advantage that if you change the shared library without changing the underlying Libmarpa -- say you change the way you build it, or that you decide to build from an fork which has not bumped the Libmarpa number, or has done so in an inconsistent way --
18:18 jeffreykegler then it's not a problem.
18:51 jeffreykegler As an example, Fedora 15 (Lovelock) is Linux 2.6.38, and Fedora 16 (Verne) is Linux 3.1.0 -- almost no relationship between the version number of Fedora and that of the Linux being re-packaged.
22:13 ronsavage joined #marpa

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary