Re: LEG: Optimisation and porting - assembly
Hi Rafael,
On Thu, Apr 04, 2013 at 09:06:11AM +0200, Rafael Laboissiere wrote:
> That seems difficult to happen. See the files:
>
> external/espeak/READ_ME.TXT
> external/glpk/READ_ME.TXT
> external/flac/READ_ME.TXT
> external/portaudio/READ_ME.TXT
> external/mp3/mp3.h
Uhmmm ...
> My understanding of the development of Praat is that the authors
> tend to be quite idiosyncratic,
I'm happy that we learned to know each other last year in Grenoble. So
I know you are a very nice and polite person which perfectly explains
this nice wording. :-)
> and that for two reasons: first,
> Praat is a tool written by linguists and used mainly by linguists.
> Second, the majority of Praat users seem to run it on MacOS and
> Windows. That said, my feeling is that any Unix-related
> improvements (like porting to autotools or CMake) will be hard to
> get integrated upstream.
I admit I'm totally uneducated about these other OSes and have no idea
how common the above build systems are there.
> >I admit I do not really rise my hand to volunteer writing a
> >portable build system for praat but from a very quick look onto
> >the code it does not look that hard to port it to autotools or
> >cmake. If upstream might consider a patch for the build system
> >this could even reduce the maintenance work inside Debian in the
> >long term.
>
> I wrote a minimal patch for compiling Praat against libgsl0-dev that
> seems to work. However, porting the building system to use the
> native glpk, flac, mad, portaudio and espeak libraries seems
> complicated to me. I will contact the upstream authors about this
> and will commit my changes as soon as I can.
I know that you have good contact to upstream which is for sure a very
important point here. IMHO there is no need for any hurry here but
penetrating them with the idea that following some well accepted rules
about the usage of libraries could have advantages over idiosyncrasy.
There might come some day (see current discussion on debian-devel about
making the release process more smooth) when we decide to shrink the
Debian package pool from leaf packages and if I were in the shoes of
Debian security team I would at first pick from the list of packages
that are incorporating copies of common libraries. In Debian Med we are
definitely dealing with leaf packages and I personally have the goal to
make sure that these are following rules that are acceptable for the
hard working teams inside Debian (security, release) and they will never
have a reason to point fingers on Debian Med.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: