Hi Andrew,
Ok, I reviewed the dlopen (Linux) and LoadLibrary (Windows) system
calls for this area.
> On Fri, 2009-11-06 at 16:18 -0500, Steve Huston wrote:
> > ...
> > A startup script can always set LD_LIBRARY_PATH.
>
> It can't set a path without potentially affecting the shared
libraries
> th
On Fri, 2009-11-06 at 16:18 -0500, Steve Huston wrote:
> ...
> A startup script can always set LD_LIBRARY_PATH.
It can't set a path without potentially affecting the shared libraries
that the executable itself loads. So I don't think this is a viable
solution. Setting LD_LIBRARY_PATH itself is gen
On 11/06/2009 03:53 PM, Andrew Stitcher wrote:
On Fri, 2009-11-06 at 09:15 -0500, Alan Conway wrote:
On 11/05/2009 12:23 PM, Andrew Stitcher wrote:
On Thu, 2009-11-05 at 10:07 -0500, Alan Conway wrote:
...
There is another issue and I'm not sure how to resolve it.
Some modules (e.g. xml, clus
Hello!
On Fri, Oct 30, 2009 at 11:03:46AM -0400, Steve Huston wrote:
> It may be an idea to make install (and the equiv on Windows) before
> running the tests. Then things could be in a predictable place and
> more closely mimic what will be in a user site.
This can possibly lead into hardwired c
On 10/30/2009 01:54 PM, Steve Huston wrote:
BTW, the plan of record (at least last I knew) was to migrate
everything to CMake and drop autoconf. I've noticed that many changes
made to Makefile.am don't necessarily make it over to CMakeLists.txt
and am wondering where the commitment level is for C
On Fri, 2009-10-30 at 15:04 -0400, Steve Huston wrote:
> ...
> If it were an easy task to build such a list mechanism, doing so would
> just delay the cmake move.
>From a purely Red Hat perspective we will have to carry on using an
autoconf build for RHEL4 as long as we support qpid on it as RHEL
Hi Andrew,
> On Fri, 2009-10-30 at 13:54 -0400, Steve Huston wrote:
> > ...
> > BTW, the plan of record (at least last I knew) was to migrate
> > everything to CMake and drop autoconf. I've noticed that
> many changes
> > made to Makefile.am don't necessarily make it over to
CMakeLists.txt
> > an
On Fri, 2009-10-30 at 13:54 -0400, Steve Huston wrote:
> ...
> BTW, the plan of record (at least last I knew) was to migrate
> everything to CMake and drop autoconf. I've noticed that many changes
> made to Makefile.am don't necessarily make it over to CMakeLists.txt
> and am wondering where the co
Hi Alan,
> On 10/30/2009 11:03 AM, Steve Huston wrote:
> > Hi Alan,
> >
> >> For tests that run executables and scripts (tests that are
> >> bash scripts, python
> >> scripts) we currently are setting a lot of ad-hoc environment
> >> variables so those tests can locate exes and libraries.
> >
> >
On 10/30/2009 11:03 AM, Steve Huston wrote:
Hi Alan,
For tests that run executables and scripts (tests that are
bash scripts, python
scripts) we currently are setting a lot of ad-hoc environment
variables so those tests can locate exes and libraries.
Yes, I've been struggling with translating
Hi Alan,
> For tests that run executables and scripts (tests that are
> bash scripts, python
> scripts) we currently are setting a lot of ad-hoc environment
> variables so those tests can locate exes and libraries.
Yes, I've been struggling with translating that for Cmake on both
Linux and Win
For tests that run executables and scripts (tests that are bash scripts, python
scripts) we currently are setting a lot of ad-hoc environment variables so those
tests can locate exes and libraries.
I propose to rationalize this as follows:
1. Rewrite the tests with NO paths on executables or l
12 matches
Mail list logo
