buildenv.pl/buildenv.bat

Magnus Hagander wrote:

Hi!

When you redid the msvc build stuff you seem to have missed the
documentatino.. Specifically, I notice that buildenv.pl isn't documented -
docs still say buildenv.bat is the way to go.

Also, do we now have both buildenv.bat and buildenv.pl? (I have them both
in my environment, but that could be a result of being lazy)

builddoc.bat still seems to require buildenv.bat.

/D

Hi All,

I am trying to do a regression testing on the version
installed.

Now on the installed version of postgreSQL-8.2.4 with
the service started, and at the regress filder, I run
the command "gmake installcheck", when I run this
command I get the following message:

GNUmakefile:15: ../../../src/Makefile.global: No such
file or directory
GNUmakefile:78: /src/Makefile.shlib: No such file or
directory
gmake: *** No rule to make target
`/src/Makefile.shlib'. Stop.

Can anyone please tell me why am I getting this
message and the solution for the same.

Thanks in advance
Regards
Cinu Kuriakose

Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php

cinu wrote:

GNUmakefile:15: ../../../src/Makefile.global: No such
file or directory
GNUmakefile:78: /src/Makefile.shlib: No such file or
directory
gmake: *** No rule to make target
`/src/Makefile.shlib'. Stop.

You need to run "configure" first (found in the top-level directory), so
that certain files are generated.

--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick." (Andrew Sullivan)

Magnus Hagander <magnus@hagander.net> writes:

When you redid the msvc build stuff you seem to have missed the
documentatino.. Specifically, I notice that buildenv.pl isn't documented -
docs still say buildenv.bat is the way to go.

On a related note, I was wondering yesterday if there are any obsolete
statements here:
http://developer.postgresql.org/pgdocs/postgres/install-win32-libpq.html

regards, tom lane

On Mon, Dec 03, 2007 at 10:52:15AM -0500, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

When you redid the msvc build stuff you seem to have missed the
documentatino.. Specifically, I notice that buildenv.pl isn't documented -
docs still say buildenv.bat is the way to go.

On a related note, I was wondering yesterday if there are any obsolete
statements here:
http://developer.postgresql.org/pgdocs/postgres/install-win32-libpq.html

No, I refreshed that page back-when. It's used for the frontend-only build
that can use earlier versions of visual studio. It also supports 64-bit
libpq which the main build doesn't (yet).

//Magnus

Magnus Hagander wrote:

Hi!

When you redid the msvc build stuff you seem to have missed the
documentatino.. Specifically, I notice that buildenv.pl isn't documented -
docs still say buildenv.bat is the way to go.

Also, do we now have both buildenv.bat and buildenv.pl? (I have them both
in my environment, but that could be a result of being lazy)

My recollection is that I changed the minimum amount necessary, because
I was expecting us to go into beta at anmy moment (silly me). That might
be why we still have both. There was an expectation that some cleanup
might be required during 8.4 development. I know I left other .bat files
as wrappers for the perl scripts, but that's obviously not appropriate
here. I'll see if I can adjust builddoc.bat so we can get rid of
buildenv.bat.

As for documentation, you're probably right, I could easily have missed
it. I'll look into it.

cheers

andrew

On Mon, 2007-12-03 at 12:15 -0500, Andrew Dunstan wrote:

Magnus Hagander wrote:

Hi!

When you redid the msvc build stuff you seem to have missed the
documentatino.. Specifically, I notice that buildenv.pl isn't documented -
docs still say buildenv.bat is the way to go.

Also, do we now have both buildenv.bat and buildenv.pl? (I have them both
in my environment, but that could be a result of being lazy)

My recollection is that I changed the minimum amount necessary, because
I was expecting us to go into beta at anmy moment (silly me). That might
be why we still have both. There was an expectation that some cleanup
might be required during 8.4 development. I know I left other .bat files
as wrappers for the perl scripts, but that's obviously not appropriate
here. I'll see if I can adjust builddoc.bat so we can get rid of
buildenv.bat.

As for documentation, you're probably right, I could easily have missed
it. I'll look into it.

Great. Let me know if you need me to poke at anything.

//Magnus

Magnus Hagander wrote:

On Mon, 2007-12-03 at 12:15 -0500, Andrew Dunstan wrote:

Magnus Hagander wrote:

Hi!

When you redid the msvc build stuff you seem to have missed the
documentatino.. Specifically, I notice that buildenv.pl isn't documented -
docs still say buildenv.bat is the way to go.

Also, do we now have both buildenv.bat and buildenv.pl? (I have them both
in my environment, but that could be a result of being lazy)

My recollection is that I changed the minimum amount necessary, because
I was expecting us to go into beta at anmy moment (silly me). That might
be why we still have both. There was an expectation that some cleanup
might be required during 8.4 development. I know I left other .bat files
as wrappers for the perl scripts, but that's obviously not appropriate
here. I'll see if I can adjust builddoc.bat so we can get rid of
buildenv.bat.

As for documentation, you're probably right, I could easily have missed
it. I'll look into it.

Great. Let me know if you need me to poke at anything.

OK, I'm thinking that the best way might be to do away with buildenv.bat
altogether and replace the remaining references to it in .bat files with
something like this fragment:

if not exist src\tools\msvc\buildenv.pl goto nobuildenv
perl -e "require 'src/tools/msvc/buildenv.pl'; while(($k,$v) = each
%ENV) { print qq[\@SET $k=$v\n]; }" > tmp.bat
call tmp.bat
del tmp.bat
:nobuildenv

and adjust the docs accordingly.

Thoughts?

cheers

andrew

On Tue, Dec 04, 2007 at 09:31:30AM -0500, Andrew Dunstan wrote:

Magnus Hagander wrote:

My recollection is that I changed the minimum amount necessary, because
I was expecting us to go into beta at anmy moment (silly me). That might
be why we still have both. There was an expectation that some cleanup
might be required during 8.4 development. I know I left other .bat files
as wrappers for the perl scripts, but that's obviously not appropriate
here. I'll see if I can adjust builddoc.bat so we can get rid of
buildenv.bat.

As for documentation, you're probably right, I could easily have missed
it. I'll look into it.

Great. Let me know if you need me to poke at anything.

OK, I'm thinking that the best way might be to do away with buildenv.bat
altogether and replace the remaining references to it in .bat files with
something like this fragment:

if not exist src\tools\msvc\buildenv.pl goto nobuildenv
perl -e "require 'src/tools/msvc/buildenv.pl'; while(($k,$v) = each
%ENV) { print qq[\@SET $k=$v\n]; }" > tmp.bat
call tmp.bat
del tmp.bat
:nobuildenv

and adjust the docs accordingly.

Thoughts?

Urgh.

I thought you specifically changed the earlier scripts to *avoid* having
them create a temporary file and then execute it. Which I agreed with :-)

I think I'd prefer we just get rid of the .bat's completely then.

I wonder if we are daring enough to do it so late in the cycle, though..

//Magnus

Magnus Hagander wrote:

On Tue, Dec 04, 2007 at 09:31:30AM -0500, Andrew Dunstan wrote:

Magnus Hagander wrote:

My recollection is that I changed the minimum amount necessary, because
I was expecting us to go into beta at anmy moment (silly me). That might
be why we still have both. There was an expectation that some cleanup
might be required during 8.4 development. I know I left other .bat files
as wrappers for the perl scripts, but that's obviously not appropriate
here. I'll see if I can adjust builddoc.bat so we can get rid of
buildenv.bat.

As for documentation, you're probably right, I could easily have missed
it. I'll look into it.

Great. Let me know if you need me to poke at anything.

OK, I'm thinking that the best way might be to do away with buildenv.bat
altogether and replace the remaining references to it in .bat files with
something like this fragment:

if not exist src\tools\msvc\buildenv.pl goto nobuildenv
perl -e "require 'src/tools/msvc/buildenv.pl'; while(($k,$v) = each
%ENV) { print qq[\@SET $k=$v\n]; }" > tmp.bat
call tmp.bat
del tmp.bat
:nobuildenv

and adjust the docs accordingly.

Thoughts?

Urgh.

I thought you specifically changed the earlier scripts to *avoid* having
them create a temporary file and then execute it. Which I agreed with :-)

I think I'd prefer we just get rid of the .bat's completely then.

I wonder if we are daring enough to do it so late in the cycle, though..

I did specifically do that, but I can't see a small workaround here that
doesn't use this mechanism, since there's no eval function in the
Windows shell.

I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late then. I did just
enough to make running the whole thing with the buildfarm client work
reliably.

I think we could reasonably get away with this for one cycle and clean
it up more thoroughly in 8.4. There are exactly four places that use
buildenv.bat: install.bat, builddoc.bat, pgbison,bat and pgflex.bat. Of
these, the only one that really matters, I suspect, is builddoc.bat, but
if we fix it we should do so consistently.

cheers

andrew

OK, I'm thinking that the best way might be to do away with buildenv.bat
altogether and replace the remaining references to it in .bat files with
something like this fragment:

if not exist src\tools\msvc\buildenv.pl goto nobuildenv
perl -e "require 'src/tools/msvc/buildenv.pl'; while(($k,$v) = each
%ENV) { print qq[\@SET $k=$v\n]; }" > tmp.bat
call tmp.bat
del tmp.bat
:nobuildenv

and adjust the docs accordingly.

Thoughts?

Urgh.

I thought you specifically changed the earlier scripts to *avoid* having
them create a temporary file and then execute it. Which I agreed with :-)

I think I'd prefer we just get rid of the .bat's completely then.

I wonder if we are daring enough to do it so late in the cycle, though..

I did specifically do that, but I can't see a small workaround here that
doesn't use this mechanism, since there's no eval function in the
Windows shell.

Right.

I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late then. I did just
enough to make running the whole thing with the buildfarm client work
reliably.

Probably, yeah. Maybe we're better off just documenting that you need both files in some cases, rather than putting in something we don't like.

I think we could reasonably get away with this for one cycle and clean
it up more thoroughly in 8.4. There are exactly four places that use
buildenv.bat: install.bat, builddoc.bat, pgbison,bat and pgflex.bat. Of
these, the only one that really matters, I suspect, is builddoc.bat, but
if we fix it we should do so consistently.

install should just use the perl version,no? That should be a simple enough fix to get into 8.3.

builddoc is, as you say, fairly important.

bison/flex is not really needed (well, the buildenv part) for commandline build, but they're required for builds from inside the gui.

/Magnus

Magnus Hagander wrote:

I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late then. I did just
enough to make running the whole thing with the buildfarm client work
reliably.

Probably, yeah. Maybe we're better off just documenting that you need both files in some cases, rather than putting in something we don't like.

Frankly, I'd rather live with more or less invisible ugliness for one
release than have to document it and put the burden on users to set up
two environments.

cheers

andrew

I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late then. I did just
enough to make running the whole thing with the buildfarm client work
reliably.

Probably, yeah. Maybe we're better off just documenting that you need both files in some cases, rather than putting in something we don't like.

Frankly, I'd rather live with more or less invisible ugliness for one
release than have to document it and put the burden on users to set up
two environments.

I don't really like the idea of shipping withb documentation that states you should do one thing, and it won't work... It's not invisible at all. If you follow the documentation, you can't build...

/Magnus

Magnus Hagander wrote:

I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late then. I did just
enough to make running the whole thing with the buildfarm client work
reliably.

Probably, yeah. Maybe we're better off just documenting that you need both files in some cases, rather than putting in something we don't like.

Frankly, I'd rather live with more or less invisible ugliness for one
release than have to document it and put the burden on users to set up
two environments.

I don't really like the idea of shipping withb documentation that states you should do one thing, and it won't work... It's not invisible at all. If you follow the documentation, you can't build...

You seem to have misunderstood what I am suggesting. Of course we should
document use of buildenv.pl in addition to the hacky fix to the .bat
files. The hack is the part that would be invisible. The docs would be
visible and contain what would be our ongoing practice.

cheers

andrew

On Sat, 2007-12-08 at 11:34 -0500, Andrew Dunstan wrote:

Magnus Hagander wrote:

I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late then. I did just
enough to make running the whole thing with the buildfarm client work
reliably.

Probably, yeah. Maybe we're better off just documenting that you need both files in some cases, rather than putting in something we don't like.

Frankly, I'd rather live with more or less invisible ugliness for one
release than have to document it and put the burden on users to set up
two environments.

I don't really like the idea of shipping withb documentation that states you should do one thing, and it won't work... It's not invisible at all. If you follow the documentation, you can't build...

You seem to have misunderstood what I am suggesting. Of course we should
document use of buildenv.pl in addition to the hacky fix to the .bat
files. The hack is the part that would be invisible. The docs would be
visible and contain what would be our ongoing practice.

Correct, I was misunderstanding it :-)

I still can't say I like that hack though. I'd rather document that you
have to do it in the .bat file for docs + gui build.

But it's better than what I thought you were proposing :-)

//Magnus

Magnus Hagander wrote:

You seem to have misunderstood what I am suggesting. Of course we should
document use of buildenv.pl in addition to the hacky fix to the .bat
files. The hack is the part that would be invisible. The docs would be
visible and contain what would be our ongoing practice.

Correct, I was misunderstanding it :-)

I still can't say I like that hack though. I'd rather document that you
have to do it in the .bat file for docs + gui build.

But it's better than what I thought you were proposing :-)

Well, I honestly think we can live with it for one cycle. As soon as 8.4
opens I'll get to work converting these .bat files to pure one line
wrappers.

Meanwhile, here's the proposed patch. If you want something else you'll
have to do it.

I don't know how many people regularly build on Windows other than you,
me and Dave.

cheers

andrew

On Sun, Dec 09, 2007 at 02:40:37PM -0500, Andrew Dunstan wrote:

Magnus Hagander wrote:

You seem to have misunderstood what I am suggesting. Of course we should
document use of buildenv.pl in addition to the hacky fix to the .bat
files. The hack is the part that would be invisible. The docs would be
visible and contain what would be our ongoing practice.

Correct, I was misunderstanding it :-)

I still can't say I like that hack though. I'd rather document that you
have to do it in the .bat file for docs + gui build.

But it's better than what I thought you were proposing :-)

Well, I honestly think we can live with it for one cycle. As soon as 8.4
opens I'll get to work converting these .bat files to pure one line
wrappers.

Ok. We obviously don't agree on what to do here, so let's open it up for somebody
else to comment on what they think is best.

My take is document the fact that you have to do it twice. Andrews is this
patch.

Meanwhile, here's the proposed patch. If you want something else you'll
have to do it.

I don't know how many people regularly build on Windows other than you,
me and Dave.

I know a couple of others. But - it was Dave that got bitten by this thing
first, which is when I noticed it and brought it up :-P

//Magnus

Magnus Hagander wrote:

Well, I honestly think we can live with it for one cycle. As soon as 8.4
opens I'll get to work converting these .bat files to pure one line
wrappers.

Ok. We obviously don't agree on what to do here, so let's open it up for somebody
else to comment on what they think is best.

My take is document the fact that you have to do it twice. Andrews is this
patch.

Nobody else seems to care :-)

My reasoning is that I don't want to make people change their setups in
future. The should just be able to set up buildenv.pl now and continue
to use it even when I've fixed the .bat files next release.

Writing and calling a temp .bat file might be yucky - having to keep two
environment files is a lot more yucky, IMNSHO, and we shouldn't make
people do it.

cheers

andrew

Andrew Dunstan wrote:

Writing and calling a temp .bat file might be yucky - having to keep two
environment files is a lot more yucky, IMNSHO, and we shouldn't make
people do it.

+1

/D