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
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
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 sinc
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 programs.
On Fri, 2008-04-18 at 23:16 +0300, Roumen Petrov wrote:
> For my users, from make and some wrapper script, I setup environment,
> run some servers (as example openldap with preloaded data) run
> un-installed programs so my users see that things work before to
> install.
Ok, then this feature wi
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 unins
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
n
On Fri, 2008-04-18 at 14:36 -0500, Bob Friesenhahn wrote:
>
> I assume that it works. Of course it does not work with some
> IDE-based debuggers. It can be made to work with programs like 'ddd'
> and 'emacs' which talk to a traditional debugger over a pseudo-tty or
> pipe.
autotool-aware IDE
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, 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 w
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 stop
* 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
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 featur
* 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 servic
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.
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
Bob Friesenhahn wrote:
On Fri, 18 Apr 2008, Roumen Petrov wrote:
And if application don't read environment, next request is libtool
wrapper script to pass arguments to application command line.
The whole idea is libtool overkill.
This statement is a little "over the top". Why are you so v
* 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.
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 locatio
On Fri, 18 Apr 2008, Roumen Petrov wrote:
And if application don't read environment, next request is libtool wrapper
script to pass arguments to application command line.
The whole idea is libtool overkill.
This statement is a little "over the top". Why are you so vehemently
against exten
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.
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 differen
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 appr
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, yeah,
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 su
* Bob Friesenhahn wrote on Thu, Apr 17, 2008 at 11:40:47PM CEST:
> 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?
> It seems to me that the proper place to fix this is at the
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 wou
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 e
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 e
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
* 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 outp
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
* 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 (pa
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
[ 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 ironi
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 ]
>
>>> Wh
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
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 proble
[ 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,
Sorry for the delay again.
* Behdad Esfahbod wrote on Thu, Mar 09, 2006 at 04:59:38PM CET:
> On Wed, 1 Mar 2006, Ralf Wildenhues wrote
39 matches
Mail list logo
