| From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | Edmund Mergl <E(dot)Mergl(at)bawue(dot)de> |
| Cc: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, Maarten Boekhold <boekhold(at)tibco(dot)com>, Postgres Hackers List <hackers(at)postgreSQL(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Cristian Gafton <gafton(at)redhat(dot)com> |
| Subject: | Re: [HACKERS] Perl library (was Building Postgres) |
| Date: | 1999-06-29 01:36:11 |
| Message-ID: | 3778230B.B7205BF3@alumni.caltech.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> cd interfaces/pgsql_perl5
> perl Makefile.PL
> make test
> su
> make install
The rpm format would prefer to build *all* files on a source machine,
and then move them from the rpm file into the appropriate places on
target machines. The problem is that, apparently,
perl Makefile.PL
generates paths which are *very* specific to the version of perl on
the source machine, and which may not be compatible with versions of
perl on the target machines. Assuming that the code generated is a bit
more tolerant of version changes in perl, then I need to figure out
where the code would go on the target machines. One possibility is to
simply lift all of the perl5 source tree into the rpm, and actually do
the build on the target machine from scratch. afaik, this is *not* the
preferred style for rpms.
Mark Hoffman and Oliver Elphick (who also has helped with my python
questions) have given me some good clues; I'll keep asking questions
until I can get something which works...
- Thomas
--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-06-29 02:04:08 | Re: [HACKERS] Perl library (was Building Postgres) |
| Previous Message | Chris Bitmead | 1999-06-28 23:51:40 | Re: [HACKERS] Severe SUBSELECT bug in 6.5 CVS |