From: | Thomas Swan <tswan(at)idigx(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Two weeks to feature freeze |
Date: | 2003-06-27 15:43:04 |
Message-ID: | 3EFC6608.2050007@idigx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
>Thomas Swan writes:
>
>
>
>>I just am really concerned about the uninstall/clean up phase and how
>>that can be done in an orderly fashion. Unless the process can start
>>from a clean state again, then it won't be valid.
>>
>>
>
>The only clean state is if you remove the entire source tree and check it
>out again. (Of course to save bandwidth, you copy the checked out source
>tree to a temporary location, do your testing, and then remove that
>temporary tree.) Relying on make clean or make uninstall is flawed,
>because those are among the things you want to test.
>
That sounds plausible. Should we let everything stay in the compilers
directory. Something like the configure --prefix=$TEST_ROOT and that
way we can have the whole thing run as one user in one directory so that
system wide impact is minimal. I guess what I'm concerned with is
running this on a clean system, and then leaving unknown artifacts
behind. Can/does make install output each file it's copying and where
to. Capturing that output would make life easier for clean up of
things installed outside of the work directory, and provide a more
controlled environment.
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-06-27 15:52:56 | Re: pg_guc |
Previous Message | Josh Berkus | 2003-06-27 15:39:21 | Re: CODE SUBMISSION FOR NEXT RELEASE |