Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user
cannot go in build-dir and just to run secure shell daemon/client.
And if you are happy with that, good for you. In GNOME though, we want
our users to be able to run uninstalled
Hi Paolo,
* Paolo Bonzini wrote on Tue, Apr 22, 2008 at 04:32:23PM CEST:
In GNU Smalltalk, ./gst is used if you don't need to load any plugin,
while tests/gst is used if you need plugins; tests/gst is created by
config.status. Most of the time launching ./gst is enough; and since
its
On Tue, 2008-04-22 at 16:32 +0200, Paolo Bonzini wrote:
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user
cannot go in build-dir and just to run secure shell daemon/client.
And if you are happy with that, good for you. In GNOME
In GNU Smalltalk, ./gst is used if you don't need to load any plugin,
while tests/gst is used if you need plugins; tests/gst is created by
config.status. Most of the time launching ./gst is enough; and since
its startup time is much faster than tests/gst, I didn't feel the need
to use
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 02:32 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default
* Roumen Petrov wrote on Fri, Apr 18, 2008 at 08:32:23PM CEST:
About no way to fix this problem with autotools. Why ?
As example libxml can run binaries from build dir. In one of the tests
is created specific xml catalog and application is run with this catalog
instead with system.
OK,
On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote:
In some cases application depend from other services.
In this case a specific to project wrapper script has to run
services,
to check if service is run, to run project application and when
application finish to stop service. The test
On Fri, 2008-04-18 at 21:32 +0300, Roumen Petrov wrote:
About no way to fix this problem with autotools. Why ?
As example libxml can run binaries from build dir. In one of the
tests
is created specific xml catalog and application is run with this
catalog
instead with system.
Stop
* Roumen Petrov wrote on Fri, Apr 18, 2008 at 08:53:12PM CEST:
In some cases application depend from other services.
In this case a specific to project wrapper script has to run services,
to check if service is run, to run project application and when
application finish to stop service.
On Fri, 18 Apr 2008, Roumen Petrov wrote:
Because I think that modules/application/packages/etc should do their best
work. I don't think that a particular package hast o support partially or to
implement very basic functionality. The est example is microsoft software
where application is
* Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST:
The only substantial change is for static builds which currently
don't have a wrapper.
Yes.
The static build is a more significant concern since static builds are
often used for debugging purposes and if we hide the static
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote:
In some cases application depend from other services.
In this case a specific to project wrapper script has to run
services,
to check if service is run, to run project application and when
application finish to
On Fri, 18 Apr 2008, Ralf Wildenhues wrote:
We need to make sure
that it is both possible to obtain the necessary run-time environment,
and to run the debugger on the correct binary. Proposals for the
cleanest way to do that are appreciated.
Well, did this cease to work (except for the bug
Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST:
The only substantial change is for static builds which currently
don't have a wrapper.
Yes.
The static build is a more significant concern since static builds are
often used for debugging purposes and if
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user
cannot go in build-dir and just to run secure shell daemon/client.
And if you are happy with that, good for you. In GNOME though, we want
our users to be able to run uninstalled programs. If this feature is
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user
cannot go in build-dir and just to run secure shell daemon/client.
And if you are happy with that, good for you.
:)
In GNOME
Ohh no
though, we want
our users to be able to run
On Tue, 2006-06-13 at 17:00 -0400, Ralf Wildenhues wrote:
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
Hi Behdad, everyone,
Hi again,
Sorry for the delay again.
So, yeah, replying after two
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of project regression test suite.
The project is responsible to set appropriate test
On Thu, 17 Apr 2008, Behdad Esfahbod wrote:
If running uninstalled build is not a goal, why bother about
LD_LIBRARY_PATH'ing the uninstalled library path at all?
I feel your pain. As a workaround, for my own software I add a small
script which exports environment variables prior to running
On Thu, 2008-04-17 at 16:40 -0500, Bob Friesenhahn wrote:
An unfortunate thing is that not all software is configured the same.
For example, my own software supports independent configuration for
the location of different types of files. A single top prefix
environment variable would not
On Fri, 2008-04-18 at 00:45 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of
Behdad Esfahbod wrote:
On Tue, 2006-06-13 at 17:00 -0400, Ralf Wildenhues wrote:
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
Hi Behdad, everyone,
Hi again,
Sorry for the delay again.
So,
Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of project regression test suite.
The project is responsible to set
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.
There is no significant
On Fri, 2008-04-18 at 02:32 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default location.
I'm
Ralf Wildenhues wrote:
Hi Gary,
Hallo Ralf!
* Gary V. Vaughan wrote on Wed, Jun 14, 2006 at 01:11:45PM CEST:
Ralf Wildenhues wrote:
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
What do you
[ let's drop bug-libtool ]
* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:03:40PM CEST:
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Wed, Jun 14, 2006 at 01:11:45PM CEST:
I have no problem with the principle, but as the patch stands there are
idiosyncracies that need ironing out
Hallo Ralf!
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:03:40PM CEST:
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Wed, Jun 14, 2006 at 01:11:45PM CEST:
I have no problem with the principle, but as the patch stands there are
idiosyncracies that need ironing
* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:57:42PM CEST:
Ralf Wildenhues wrote:
So could you please list the technical problems you see with this patch,
so I can fix them, if any?
Starting to add new features on this side of the 2.0 release is like
the road to hell (paved with
Hallo Ralf,
[adding bug-m4, and quoting generously to remind us to address the
issues you raise]
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:57:42PM CEST:
Ralf Wildenhues wrote:
So could you please list the technical problems you see with this patch,
so I can
* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 02:00:28PM CEST:
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:57:42PM CEST:
Ralf Wildenhues wrote:
${1+$@} 2/tmp/m4-$$
This is very very unfortunate for debugging. I won't see the output
when it
Hallo Ralf,
Ralf Wildenhues wrote:
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
[[snip]]
What do you think? OK for HEAD right now, or do you think this is too
intrusive now?
I have no problem
Hi Gary,
* Gary V. Vaughan wrote on Wed, Jun 14, 2006 at 01:11:45PM CEST:
Ralf Wildenhues wrote:
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
What do you think? OK for HEAD right now, or do
33 matches
Mail list logo
