Ralf Wildenhues | 9 Apr 13:14 2008
Picon
Picon

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

Hello Josh,

can we limit followups to a subset of this impressive array of mailing
lists?  Say, to <libtool <at> gnu.org>?  That would be readable at
<http://thread.gmane.org/gmane.linux.debian.devel.general/126905>.
Thanks.

* Josh Triplett wrote on Wed, Apr 09, 2008 at 12:34:18PM CEST:
> Libtool knows how to handle libraries for umpteen different systems,
> including many ancient systems that have terrible shared library
> support.  It has some extensive shell script logic to figure out how
> to build libraries for your system, and how to compile objects that go
> in those libraries.  This logic does an amazingly impressive job of
> coping with adverse conditions.  However, this logic all lives in an
> ~8500 line, ~250kB shell script, which runs *every single time you
> compile a source file*.
> 
> This does not do wonders for performance.

Curious: can you please state which Libtool version you timed against,
and if not 2.2.x, redo timing against 2.2.2?  Not that I expect wonders,
but I expect something better than what you measured.

Thanks,
Ralf

_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool

(Continue reading)

Roland Mainz | 11 Apr 16:15 2008

"libtool" performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half

Josh Triplett wrote:
> 
> Many packages use GNU autotools (automake and autoconf) to build, to
> the point that "./configure && make" represents one of the most common
> build procedures for Free Software packages.  Libraries using
> autotools typically use GNU Libtool, partly because it works on almost
> any system and partly because autotools makes it difficult to do
> otherwise.  Packages which use these libraries sometimes use libtool
> as well.
> 
> Yet for many of these libraries and other packages, more than half of
> the build time goes into running the libtool shell script.
> 
> Libtool knows how to handle libraries for umpteen different systems,
> including many ancient systems that have terrible shared library
> support.  It has some extensive shell script logic to figure out how
> to build libraries for your system, and how to compile objects that go
> in those libraries.  This logic does an amazingly impressive job of
> coping with adverse conditions.  However, this logic all lives in an
> ~8500 line, ~250kB shell script, which runs *every single time you
> compile a source file*.
> 
> This does not do wonders for performance.
[snip]

Uhm... a while ago we hit the same problem and did some research on the
issue and  a diffent route by switching the shell used by libtool from
"bash" to "ksh93" and did some minor modifications (e.g. enable more
ksh93 builtin commands, replace some of the "sed" usage by
builtin-string operators (which are common between "bash" and "ksh93"
(Continue reading)

Matt Jones | 20 Apr 11:11 2008

help with starting python thread in dbus call


Basically I have a python dbus server that needs to start a thread when 
a method is called. Like so:

     <at> dbus.service.method(dbus_interface='EncodingServer.Interface', 
in_signature='', out_signature='')
    def start_encoding(self):
        # Here we start the encoder thread then return. The thread 
should continue after we return, but it freezes.
        encoder = EncoderThread() # this is a thread like: 
EncoderThread(threading.Thread)
        encoder.start()

It looks like this is an issue with the gobject mainloop blocking the 
python thread execution. I have found many posts talking about this, but 
no solution. Also note that the encoder thread could run for hours, so 
calling the method asynchronously on the client will time out, and is 
not really desired.

I've attached an example client and server to better explain my point. 
Notice that if you kill the server's main loop with control+c, the 
gobject main loop dies and the thread continues as normal.

Any help would be appreciated! Also, I'm new to dbus, so I may have a 
stupid design here.
Attachment (long_running_client.py): text/x-python, 454 bytes
Attachment (long_running_server.py): text/x-python, 1000 bytes
(Continue reading)

Domingo González | 22 Apr 20:09 2008

GUADEMY 2008: Final program and online participation

Hi,

The final program of GUADEMY and more information is available in this link:
http://www.guademy.org/programa.php?lang=en

To enable participation of all people in GUADEMY 2008, we are going to
broadcast the event through video streaming, and we have configured a
Jabber room as a return channel for enable the online participation in
the discussions.

Friday, 25 April 2008

* GUADEMY 2008 Inaugural Ceremony
* Introduction Forum: current state and objectives
* QtWebKit
by Mr. Holger FREYTHER (FU-Berlin)
* Novell GNOME-KDE sharing project GNOME/KDE sharing and FreeDesktop.org
by Mr. Rodrigo MOYA (GNOME Hispano); Mr. Will STEPHENSON (Novell, KDE)
* freedesktop.org specifications: are they boring?
by Mr. Vincent UNTZ (Novell, GNOME)
* Developing on GNU
by Mr. Aleix POL (KDE)

Saturday, 26 April 2008

* The future of Free Software graphical toolkits
by Mr. Carlos GARNACHO (Imendio AB); Mr. Holger FREYTHER (FU-Berlin); *
Mr. Javier FERNANDEZ GARCíA-BOENTE (Igalia)
* Metadata management in desktop
by Mr. Ivan FRADE (Nokia)
(Continue reading)

Josh Triplett | 9 Apr 12:34 2008
Picon

Announcing Dolt, a drop-in Libtool replacement which cuts build times in half


Many packages use GNU autotools (automake and autoconf) to build, to
the point that "./configure && make" represents one of the most common
build procedures for Free Software packages.  Libraries using
autotools typically use GNU Libtool, partly because it works on almost
any system and partly because autotools makes it difficult to do
otherwise.  Packages which use these libraries sometimes use libtool
as well.

Yet for many of these libraries and other packages, more than half of
the build time goes into running the libtool shell script.

Libtool knows how to handle libraries for umpteen different systems,
including many ancient systems that have terrible shared library
support.  It has some extensive shell script logic to figure out how
to build libraries for your system, and how to compile objects that go
in those libraries.  This logic does an amazingly impressive job of
coping with adverse conditions.  However, this logic all lives in an
~8500 line, ~250kB shell script, which runs *every single time you
compile a source file*.

This does not do wonders for performance.

Meanwhile, modern systems such as GNU/Linux have reasonable library
mechanisms, and need relatively little of the machinery in libtool.
On these common systems, it would significantly improve build times to
avoid running that libtool machinery for every compilation.

(Continue reading)


Gmane