buildenv.pl/buildenv.bat
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)
//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)
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
:nobuildenvand 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
:nobuildenvand 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
:nobuildenvand 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
Import Notes
Resolved by subject fallback
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
Import Notes
Resolved by subject fallback
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
Attachments:
buildenv.patchtext/x-patch; charset=iso-8859-1; name=buildenv.patchDownload
Index: doc/src/sgml/install-win32.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/install-win32.sgml,v
retrieving revision 1.42
diff -c -r1.42 install-win32.sgml
*** doc/src/sgml/install-win32.sgml 28 Nov 2007 15:42:31 -0000 1.42
--- doc/src/sgml/install-win32.sgml 9 Dec 2007 19:31:36 -0000
***************
*** 58,69 ****
Before you build, edit the file <filename>config.pl</filename> to reflect the
configuration options you want set, including the paths to libraries used.
If you need to set any other environment variables, create a file called
! <filename>buildenv.bat</filename> and put the required commands there. For
example, to add the path for bison when it's not in the PATH, create a file
containing:
<screen>
! @ECHO OFF
! SET PATH=%PATH%;c:\some\where\bison\bin
</screen>
</para>
--- 58,68 ----
Before you build, edit the file <filename>config.pl</filename> to reflect the
configuration options you want set, including the paths to libraries used.
If you need to set any other environment variables, create a file called
! <filename>buildenv.pl</filename> and put the required commands there. For
example, to add the path for bison when it's not in the PATH, create a file
containing:
<screen>
! $ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
</screen>
</para>
***************
*** 209,218 ****
</userinput>
</screen>
To change the default build configuration to debug, put the following
! in the <filename>buildenv.bat</filename> file:
<screen>
<userinput>
! set CONFIG=Debug
</userinput>
</screen>
</para>
--- 208,217 ----
</userinput>
</screen>
To change the default build configuration to debug, put the following
! in the <filename>buildenv.pl</filename> file:
<screen>
<userinput>
! $ENV{CONFIG}="Debug";
</userinput>
</screen>
</para>
***************
*** 263,269 ****
required parts first. Also, make sure that the DLLs required to load all
parts of the system (such as the Perl and Python DLLs for the procedural
languages) are present in the system path. If they are not, set it through
! the <filename>buildenv.bat</filename> file. To run the tests, run one of
the following commands from the <filename>src\tools\msvc</filename>
directory:
<screen>
--- 262,268 ----
required parts first. Also, make sure that the DLLs required to load all
parts of the system (such as the Perl and Python DLLs for the procedural
languages) are present in the system path. If they are not, set it through
! the <filename>buildenv.pl</filename> file. To run the tests, run one of
the following commands from the <filename>src\tools\msvc</filename>
directory:
<screen>
***************
*** 339,349 ****
</para></listitem>
</varlistentry>
</variablelist>
! Edit the <filename>buildenv.bat</filename> file, and add a variable for the
location of the root directory, for example:
<screen>
! @ECHO OFF
! SET DOCROOT=c:\docbook
</screen>
To build the documentation, run the command
<filename>builddoc.bat</filename>. Note that this will actually run the
--- 338,347 ----
</para></listitem>
</varlistentry>
</variablelist>
! Edit the <filename>buildenv.pl</filename> file, and add a variable for the
location of the root directory, for example:
<screen>
! $ENV{DOCROOT}='c:\docbook';
</screen>
To build the documentation, run the command
<filename>builddoc.bat</filename>. Note that this will actually run the
Index: src/tools/msvc/builddoc.bat
===================================================================
RCS file: /cvsroot/pgsql/src/tools/msvc/builddoc.bat,v
retrieving revision 1.5
diff -c -r1.5 builddoc.bat
*** src/tools/msvc/builddoc.bat 17 Mar 2007 14:01:01 -0000 1.5
--- src/tools/msvc/builddoc.bat 9 Dec 2007 19:31:36 -0000
***************
*** 1,5 ****
@echo off
! REM Adjust path for your docbook installation in buildenv.bat
REM $PostgreSQL: pgsql/src/tools/msvc/builddoc.bat,v 1.5 2007/03/17 14:01:01 mha Exp $
--- 1,5 ----
@echo off
! REM Adjust path for your docbook installation in buildenv.pl
REM $PostgreSQL: pgsql/src/tools/msvc/builddoc.bat,v 1.5 2007/03/17 14:01:01 mha Exp $
***************
*** 10,16 ****
IF EXIST ..\msvc IF EXIST ..\..\..\src cd ..\..\..
IF NOT EXIST doc\src\sgml\version.sgml goto noversion
! IF EXIST src\tools\msvc\buildenv.bat CALL src\tools\msvc\buildenv.bat
IF NOT EXIST %DOCROOT%\%OPENJADE% SET NF=OpenJade
IF NOT EXIST %DOCROOT%\docbook SET NF=docbook
--- 10,21 ----
IF EXIST ..\msvc IF EXIST ..\..\..\src cd ..\..\..
IF NOT EXIST doc\src\sgml\version.sgml goto noversion
!
! 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]; }" > bldenv.bat
! CALL bldenv.bat
! del bldenv.bat
! :nobuildenv
IF NOT EXIST %DOCROOT%\%OPENJADE% SET NF=OpenJade
IF NOT EXIST %DOCROOT%\docbook SET NF=docbook
Index: src/tools/msvc/install.bat
===================================================================
RCS file: /cvsroot/pgsql/src/tools/msvc/install.bat,v
retrieving revision 1.2
diff -c -r1.2 install.bat
*** src/tools/msvc/install.bat 26 Jun 2007 11:43:56 -0000 1.2
--- src/tools/msvc/install.bat 9 Dec 2007 19:31:36 -0000
***************
*** 13,19 ****
:RUN_INSTALL
SETLOCAL
! if exist buildenv.bat call buildenv.bat
perl install.pl "%1"
--- 13,24 ----
:RUN_INSTALL
SETLOCAL
!
! IF NOT EXIST buildenv.pl goto nobuildenv
! perl -e "require 'buildenv.pl'; while(($k,$v) = each %ENV) { print qq[\@SET $k=$v\n]; }" > bldenv.bat
! CALL bldenv.bat
! del bldenv.bat
! :nobuildenv
perl install.pl "%1"
Index: src/tools/msvc/pgbison.bat
===================================================================
RCS file: /cvsroot/pgsql/src/tools/msvc/pgbison.bat,v
retrieving revision 1.7
diff -c -r1.7 pgbison.bat
*** src/tools/msvc/pgbison.bat 7 Jul 2007 07:43:21 -0000 1.7
--- src/tools/msvc/pgbison.bat 9 Dec 2007 19:31:36 -0000
***************
*** 1,7 ****
@echo off
REM $PostgreSQL: pgsql/src/tools/msvc/pgbison.bat,v 1.7 2007/07/07 07:43:21 mha Exp $
! if exist src\tools\msvc\buildenv.bat call src\tools\msvc\buildenv.bat
SET BV=
for /F "tokens=4 usebackq" %%f in (`bison -V`) do if "!BV!"=="" SET BV=%%f
--- 1,11 ----
@echo off
REM $PostgreSQL: pgsql/src/tools/msvc/pgbison.bat,v 1.7 2007/07/07 07:43:21 mha Exp $
! 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]; }" > bldenv.bat
! CALL bldenv.bat
! del bldenv.bat
! :nobuildenv
SET BV=
for /F "tokens=4 usebackq" %%f in (`bison -V`) do if "!BV!"=="" SET BV=%%f
Index: src/tools/msvc/pgflex.bat
===================================================================
RCS file: /cvsroot/pgsql/src/tools/msvc/pgflex.bat,v
retrieving revision 1.4
diff -c -r1.4 pgflex.bat
*** src/tools/msvc/pgflex.bat 17 Mar 2007 14:01:01 -0000 1.4
--- src/tools/msvc/pgflex.bat 9 Dec 2007 19:31:36 -0000
***************
*** 1,7 ****
@echo off
REM $PostgreSQL: pgsql/src/tools/msvc/pgflex.bat,v 1.4 2007/03/17 14:01:01 mha Exp $
! if exist src\tools\msvc\buildenv.bat call src\tools\msvc\buildenv.bat
flex -V > NUL
if errorlevel 1 goto noflex
--- 1,11 ----
@echo off
REM $PostgreSQL: pgsql/src/tools/msvc/pgflex.bat,v 1.4 2007/03/17 14:01:01 mha Exp $
! 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]; }" > bldenv.bat
! CALL bldenv.bat
! del bldenv.bat
! :nobuildenv
flex -V > NUL
if errorlevel 1 goto noflex
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
On Fri, Dec 14, 2007 at 03:39:14PM +0000, Dave Page wrote:
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
Ok, I guess I'm outvoted ;-) I don't care *that* much about it, so let's do
it your way.
You need help testing that patch further, or do you consider it ready for
application? If so, go.
//Magnus
Magnus Hagander wrote:
On Fri, Dec 14, 2007 at 03:39:14PM +0000, Dave Page wrote:
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
Ok, I guess I'm outvoted ;-) I don't care *that* much about it, so let's do
it your way.You need help testing that patch further, or do you consider it ready for
application? If so, go.
Yes, please do test it - I don't use buildenv.* at all normally, as then
buildfarm client takes care of its own environment, and that's what I
usually use to build on Windows.
cheers
andrew.
On Fri, Dec 14, 2007 at 10:47:02AM -0500, Andrew Dunstan wrote:
Magnus Hagander wrote:
On Fri, Dec 14, 2007 at 03:39:14PM +0000, Dave Page wrote:
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
Ok, I guess I'm outvoted ;-) I don't care *that* much about it, so let's do
it your way.You need help testing that patch further, or do you consider it ready for
application? If so, go.Yes, please do test it - I don't use buildenv.* at all normally, as then
buildfarm client takes care of its own environment, and that's what I
usually use to build on Windows.
It works in my two standalone environments (win32 and win64 machine),
so I've applied the patch now to get full buildfarm testing.
//Magnus