Re: [asmlib] - Library of optimized subroutines coded in assembly language.

[Andreas Tille <andreas@an3as.eu>]

Hi Jorge,

On Thu, Nov 06, 2014 at 09:31:56AM +0000, Jorge Sebastião Soares wrote:
> >
> > On Wed, Nov 05, 2014 at 05:13:13PM +0000, Jorge Sebastião Soares wrote:
> > > Hi all,
> > >
> > > I have started packaging asmlib.
> > >
> > > [1] Original upstream - http://www.agner.org/optimize/
> > > [2] Upstream for Debian - https://github.com/js21/asmlib
> >
> > What does that mean "upstream for Debian"?  I admit this sounds really
> > suspicious.
> 
> 
> Upstream for Debian means a temporary upstream placeholder to use for
> package building, whilst the KMC authors have a discussion with the asmlib
> author, to try to get him to distribute his code in a VCS manner.
> If you look at [1], the code is distributed as a zip file that contains the
> compiled static libraries for several OS's and architectures. The source
> code is another zip file inside the original one. It contains a pdf plus
> other zip files. The source code itself uses a nmake makefile that performs
> cross compilation, through the use of yet another piece of code written by
> the author.

OK, I see.  However, I'd prefer a debian/get-orig-script fetching the
zipfile and extracting the source from there.
 
> There is no versioning system whatsoever for asmlib. The author simply
> states that the most up to date version is always available in [1].

There is a nice guide for upstream developers who tell you things like
this.  You should rather point upstream to

   https://wiki.debian.org/UpstreamGuide#Releases_and_Versions

than trying to fix things on behalf of upstream.  BTW, I wonder what
amount of speed gain KMC authors are expecting from a library written in
assembly?  These days compilers are really optimised.  If I see source
files like memcmp64.asm, memcpy64.asm etc I *really* wonder what I
should expect from an author who fails to comply to some basic rules
like releasing versioned tarballs.  If *I* would try to develop a piece
of software I would not rely on such code, sorry.

> > I do not see any point for not using straight upstream
> > repository.
> 
> I am hoping that the KMC authors will convince the asmlib author to
> distribute his code through a VCS.

In the sense what I wrote above I personally would be happy if KMC
authors would use plain C/C++ code and do some serious testing what
speed they really gain and how maintainable their code would be.

> >   It seems Git addicts have a lot of fun by cloning things.
> 
> I think you're assuming too much here.

Yes, you are right.  I should have checked in advance.  Sorry.

> In my view, if the upstream author sees the simplicity of what I have done,
> I believe it would be easier to convince him/her to use whatever VCS. In my
> case Git, because I am now used to it.

OK, that's a valid point.
 
> >     git import-orig --pristine-tar
> >
> > since the repository has no upstream branch.  Please try to follow our
> > zeam policy as closely as possible.  Otherwise your coworkers will have
> > trouble to
> 
> I have used it I think I just forgot to push it. It's now pushed for asmlib.

OK, confirmed that I was able to pull this.
 
> > > genomes, not as in machine code) IVA written in python by a member of my
> > > team over at the Wellcome Trust Sanger Institute.
> > >
> > > [7] Original upstream - https://github.com/sanger-pathogens/iva
> >
> > Sounds good!
> 
> At least something...

Well, it seems my murmuring was a bit depressing to you.  This was not
intended.  May be the unusual way of source distribution has fired back
to you since I did not expected this kind of trouble and was not
checking properly.
 
> I'll work through quilt patches.
> I only removed code to see if I could build the package in my machine.
> And since the nmake makefile is completely useless with make + the only
> libraries useful for Debian would be the 32bit and and 64bit Unix libraries
> + I'm not making any changes to the original source file, simply adding a
> Unix Makefile, I thought this would be a simple solution.

Here we are facing another drawback of asmlib usage:  KMC authors are
excluding promising architectures like arm64 and ppc64el which might in
the not so distant future could become relevant for tasks in
bioinformatics.
 
> > Yes, that's a static library that belongs to the libasmlib-dev package.
> > You should also create a libasm<soversion> package containing a dynamic
> > library (*.so).
> >
> > For packaging libraries compliant to [8] you are well advised to use
> > d-shlibs.  We have several examples of its usage in Debian Med Git+SVN.
> > You used it yourself in your MoM training package. :-)
> >
> 
> Thanks, I had alreayd added d-shlibs as a dependency.

Fine.

> > Yes, for sure.  I think the decision to package asmlib separately was
> > drawn in the beginning of this discussion.
> >
> 
> This email was sent to both Debian Med and Debian Mentors. I thought it
> best to be as verbose as I could be.

I missed this and I'm now CCing debian-mentors as well.
 
Summary: I would try to discuss with KMC developers whether they would
see any chance to make amslib optional and could provide the full
functionality without this library.  Writing assembly language is to the
best of my knowledge something you did in the 90th of last century.
Trying to reimplement things like memcmp, memcpy etc is something you
should avoid IMHO.

Kind regards

       Andreas.

-- 
http://fam-tille.de