Closed Bug 294088 Opened 15 years ago Closed 13 years ago

setmozenv.cmd - New batch file to set up the OS/2 dev environment available

Categories

(Firefox Build System :: General, enhancement)

Other Branch
x86
OS/2
enhancement
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: morrownr, Unassigned)

Details

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.5) Gecko/20041220
Build Identifier: n/a

During the process of setting up the dev environment I did a lot of work on the
script used to set up the dev environment.  Request my version be made available
to anyone working on Warpzilla.

Big advantage:  Error checking and logging.


Reproducible: Always
I suggest also zeroing out %config.site%, eg set CONFIG.SITE=
to stop configure from loading a config.site if %CONFIG.SITE% is defined. Might
not hurt either to check for existance of \usr\local\share\config.site and
suggesting moving it out of the way.
(In reply to comment #2)
> I suggest also zeroing out %config.site%, eg set CONFIG.SITE=
> to stop configure from loading a config.site if %CONFIG.SITE% is defined. Might
> not hurt either to check for existance of \usr\local\share\config.site and
> suggesting moving it out of the way.

Dave, can I talk you into making these mods the way you think they should be
done then upload the moded file as a new attachment?  Please include REMs that
explain why.
I just took a very quick look through the file, it will take a few days before I
can really test it. One thing I found and did not like is that it expects all
the programs under %MOZTOOLS%, like in the "SETTINGS TO FILES THAT DO NOT EXIST"
section. My setup always worked fine although I never had all the tools under
that dir but I would still get lots of error messages in the log...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: setmzenv.cmd - New batch file to set up the OS/2 dev environment available → setmozenv.cmd - New batch file to set up the OS/2 dev environment available
Contains mods with reference to comments #2 and #4
Attachment #183544 - Attachment is obsolete: true
(In reply to comment #4)
> I just took a very quick look through the file, it will take a few days before I
> can really test it. One thing I found and did not like is that it expects all
> the programs under %MOZTOOLS%, like in the "SETTINGS TO FILES THAT DO NOT EXIST"
> section. My setup always worked fine although I never had all the tools under
> that dir but I would still get lots of error messages in the log...

I've pulled the section regarding %MOZTOOLS% out of this file and will look for
a separate with to address the issue it was addressing.  I also added support
for CONFIG.SITE as suggested in comment #2.  See new attachment.
Sorry that it took so long, I only today downloaded and tested your batch file.
In the process I finally realized why the current setmozenv.cmd was REXX: the
backtoforward function. In your new batch version one needs to modify both the
OS/2 like and Unix-like paths which I find a bit annoying. But then, one does
not change that too often... I still have to build from the environment defined
by my adapted batch, but until that final test I have some further comments:
- Not clear that MZDEVDIR and MZDEVNIX need to end with \ and /. Perhaps add
"end in \" and "end in /" to the comment above.
- EMX and EMX2 do not seem to be used any more
- I don't really know why INFOPATH, EMXBOOK, and HELPNDX are defined, they don't
seem to serve any purpose in the build process
- It might be a good idea to check for the existence of LOGNAME, USER,
SYSTEMNAME before setting them.
- With time I found the following useful variables, which could be set or
perhaps put in the file being remmed out:
     rem append BuildID in the titlebar
     set MOZILLA_OFFICIAL=1
     set BUILD_OFFICIAL=1
     rem disable creating extra gecko-SDK package when running packager
     rem set NO_GECKO_SDK=1
     rem disable assertion dialog of debug builds
     rem set XPCOM_DEBUG_BREAK=warn
(In reply to comment #7)

> In the process I finally realized why the current setmozenv.cmd was REXX: the
> backtoforward function. In your new batch version one needs to modify both the
> OS/2 like and Unix-like paths which I find a bit annoying. But then, one does
> not change that too often...

I approached this rewrite of the setup script from the perspective of someone
new to the environment.  I can understand that it may be annoying for you to see
a proposed new script that does not include backtoforward support.  On the other
hand it was annoying for me to chase around and figure out what was going on
whereas in the proposed new script the flow is such that it is easy for a newby
to see what is going on.  In the end I think the situation is like you say "one
does not need to change that too often."

> I still have to build from the environment defined
> by my adapted batch, but until that final test I have some further comments:
> - Not clear that MZDEVDIR and MZDEVNIX need to end with \ and /. Perhaps add
> "end in \" and "end in /" to the comment above.

Good idea.

> - EMX and EMX2 do not seem to be used any more

Ok.  Will test here and remove unless there is a problem.

> - I don't really know why INFOPATH, EMXBOOK, and HELPNDX are defined, they
> don't seem to serve any purpose in the build process

I'm certainly willing to pull them out.  I haven't explored all settings at this
point.  I'll pull them and test.

> - It might be a good idea to check for the existence of LOGNAME, USER,
> SYSTEMNAME before setting them.

Easy to do.  I assume that you are saying that they should not be set if they
are already set?

> - With time I found the following useful variables, which could be set or
> perhaps put in the file being remmed out:
>      rem append BuildID in the titlebar
>      set MOZILLA_OFFICIAL=1
>      set BUILD_OFFICIAL=1
>      rem disable creating extra gecko-SDK package when running packager
>      rem set NO_GECKO_SDK=1
>      rem disable assertion dialog of debug builds
>      rem set XPCOM_DEBUG_BREAK=warn

Can add them in a section at the end.

I'll make these modifications, do some testing and then I'll upload a new version.

Nick
Attachment #184103 - Attachment is obsolete: true
Attachment #186551 - Flags: review+
(In reply to comment #7)

> - Not clear that MZDEVDIR and MZDEVNIX need to end with \ and /. Perhaps add
> "end in \" and "end in /" to the comment above.

Comments added to clear this up.

> - EMX and EMX2 do not seem to be used any more

This is the only issue I didn't take action on.  These two variables have
several dependencies.  Please crosscheck the dependencies.

> - I don't really know why INFOPATH, EMXBOOK, and HELPNDX are defined, they
> don't seem to serve any purpose in the build process

Deleted.

> - It might be a good idea to check for the existence of LOGNAME, USER,
> SYSTEMNAME before setting them.

Recoded.  Done.

> - With time I found the following useful variables, which could be set or
> perhaps put in the file being remmed out:
>      rem append BuildID in the titlebar
>      set MOZILLA_OFFICIAL=1
>      set BUILD_OFFICIAL=1
>      rem disable creating extra gecko-SDK package when running packager
>      rem set NO_GECKO_SDK=1
>      rem disable assertion dialog of debug builds
>      rem set XPCOM_DEBUG_BREAK=warn

Added to the end.

Nick
Attachment #186551 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 186551 [details]
 Batch file to set up the Warpzilla dev environment 

I think we are getting close, but you are not supposed to change the review
flags yourself. A few more comments:

> SET PATH=%ROOT%\foo;%PATH%

should probably be something like
  SET PATH=%MZDEVDRV%%MZDEVDIR%foo;%PATH%
as %ROOT% doesn't exist any more.

> REM - The EMX files are already installed in eCS v1.1+, however, eCS
> REM   does not set the EMX environment variable.  This batch file
> REM   assumes you have installed emx to a directory named EMX under
> REM   MZDEVDIR.  Edit the EMX setting if required.

It says on the gccsetup webpage "Add D:\EMX\DLL to your LIBPATH in CONFIG.SYS"
so we don't really need to worry about it here. Even if the user is not on eCS
the EMX DLLs needed for the various tools are probably installed and in LIBPATH
anyway.

> SET TERMCAP=%EMX2%/etc/termcap.dat
> @ECHO TERMCAP:              %TERMCAP% >> setMZenv.log
> SET TERM=os2
> @ECHO TERM:                 %TERM%    >> setMZenv.log

Does termcap.dat get installed with eCS's EMX at all? "os2" is not a valid
terminal in any case. I suggest to remove both. Even though not really needed
in the build process bash, perl etc. work very well without these settings,
using some default terminal which is much nicer than any terminal contained in
that termcap.dat.

- Please add %TOOLKIT%\bin; to path (instead of %EMX%\bin which is unused). Not
really necessary for the build process but convenient for debugging and stuff
afterwards.

- Now you can remove %EMX% and %EMX2%. :-)

- I don't think one should touch CVSROOT, at least not when just supporting the
various Mozilla based projects (the Suite, FF, TB, or even XULRunner). Perhaps
move it to SECTION_5 instead.

- For some reason I now cannot get it through the configure stage with the new
version. It always says "No such file or directory" while still listing the
correct path to both glib-config and libIDL-config. The #! header is also
correct. But now the test programs get the wrong compile flags (missing -I) and
don't compile any more. This is very strage as I couldn't find any relevant
difference between the environments of my trusted CMD and the new one...
Attachment #186551 - Flags: review+
>> SET PATH=%ROOT%\foo;%PATH%

>should probably be something like
>  SET PATH=%MZDEVDRV%%MZDEVDIR%foo;%PATH%
>as %ROOT% doesn't exist any more.

Done.  It is a dummy setting but I guess a dummy setting that makes sense is 
better than one that doesn't.


>> REM - The EMX files are already installed in eCS v1.1+, however, eCS
>> REM	 does not set the EMX environment variable.  This batch file
>> REM	 assumes you have installed emx to a directory named EMX under
>> REM	 MZDEVDIR.  Edit the EMX setting if required.

>It says on the gccsetup webpage "Add D:\EMX\DLL to your LIBPATH in CONFIG.SYS"

>so we don't really need to worry about it here. Even if the user is not on eCS

>the EMX DLLs needed for the various tools are probably installed and in
LIBPATH
>anyway.

Deleted.


>> SET TERMCAP=%EMX2%/etc/termcap.dat
>> @ECHO TERMCAP:	       %TERMCAP% >> setMZenv.log
>> SET TERM=os2
>> @ECHO TERM:		       %TERM%	 >> setMZenv.log

>Does termcap.dat get installed with eCS's EMX at all? "os2" is not a valid
>terminal in any case. I suggest to remove both. Even though not really needed
>in the build process bash, perl etc. work very well without these settings,
>using some default terminal which is much nicer than any terminal contained in

>that termcap.dat.

Deleted.  There sure seems to have been a lot of unneeded junk in the old
setmozenv.cmd.


>- Please add %TOOLKIT%\bin; to path (instead of %EMX%\bin which is unused).
Not
>really necessary for the build process but convenient for debugging and stuff
>afterwards.

Done.


>- Now you can remove %EMX% and %EMX2%. :-)

Done.  The file continues to get shorter and more simple :-)


>- I don't think one should touch CVSROOT, at least not when just supporting
the
>various Mozilla based projects (the Suite, FF, TB, or even XULRunner). Perhaps

>move it to SECTION_5 instead.

Moved to Section 5.

Nick
Attachment #186551 - Attachment is obsolete: true
I linked this bug and the attachment containing the most up-to-date version of the batch file on the new OS/2 build setup page (http://developer.mozilla.org/en/docs/OS/2_Build_Prerequisites). Once there is a way to upload .cmd file to that wiki I think we should also post it there.
Product: Firefox → Core
Version: unspecified → Other Branch
QA Contact: build.config → build-config
Well, in the time it was linked on the setup page I heard of nobody who downloaded it. There were actually four people but they all chose the original CMD... And now the original REXX-based CMDs have changed quite a bit, so this alternative batch file is outdated.

Even though I hate to have wasted Nicky's time with this, it never caught up... Resolving as WONTFIX for now.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.