https://wiki.netlabs.org/api.php?action=feedcontributions&feedformat=atom&user=GgambaNikiWiki - User contributions [en]2026-04-28T22:05:32ZUser contributionsMediaWiki 1.43.0https://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=5065Compiling XWP2008-06-11T20:42:01Z<p>Ggamba: /* Branch, trunk, tags... */ Updated to 1.08</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout XWP '''version 1.0.8''' (the latest released version):<br />
<br />
cvs checkout -r pr_0006_1-0-8 .<br />
<br />
in the XWP sources directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an initial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
* Several versions of rc.exe are around, and not all of them work well for XWP compilation. Good versions are for sure:<br />
<br />
Version 4.00.001 Jun 27 1996<br />
<br />
and<br />
<br />
Version 4.00.010 Apr 26 1999 <br />
<br />
which is essentially the same version as the above with some fixes done specifically for the Mozilla team. It was available at:<br />
<br />
ftp://ftp.software.ibm.com/ps/products/warpzilla/os2tk40rc.zip<br />
<br />
Finally, someone successfully replaced rc.exe from IBM with the one from the Open Watcom compiler, wrc.exe, that accepts much longer command lines.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
In case of problems, verify if x:\CVS\xworkplace\bin\full directory has been created. If not, create it.<br />
<br />
You have also good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\bin\xwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to '''unlock''' the files first if you are copying over your running files. Check that XWP_UNLOCK_MODULES = YES line exists in CONFIG.IN (it's down near the bottom). The Unlock utility from the LxLite package is required. If XWP_UNLOCK_MODULES should not be enough, manually unlock XWPHOOK.DLL and XWPDAEMN.EXE.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4931Compiling XWP2007-12-19T19:52:27Z<p>Ggamba: /* Compiling the beast */</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
* Several versions of rc.exe are around, and not all of them work well for XWP compilation. Good versions are for sure:<br />
<br />
Version 4.00.001 Jun 27 1996<br />
<br />
and<br />
<br />
Version 4.00.010 Apr 26 1999 <br />
<br />
which is essentially the same version as the above with some fixes done specifically for the Mozilla team. It was available at:<br />
<br />
ftp://ftp.software.ibm.com/ps/products/warpzilla/os2tk40rc.zip<br />
<br />
Finally, someone successfully replaced rc.exe from IBM with the one from the Open Watcom compiler, wrc.exe, that accepts much longer command lines.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
In case of problems, verify if x:\CVS\xworkplace\bin\full directory has been created. If not, create it.<br />
<br />
You have also good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\bin\xwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to '''unlock''' the files first if you are copying over your running files. Check that XWP_UNLOCK_MODULES = YES line exists in CONFIG.IN (it's down near the bottom). The Unlock utility from the LxLite package is required. If XWP_UNLOCK_MODULES should not be enough, manually unlock XWPHOOK.DLL and XWPDAEMN.EXE.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4930Compiling XWP2007-12-19T19:47:06Z<p>Ggamba: /* Compiling the beast */</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
* Several versions of rc.exe are around, and not all of them work well for XWP compilation. Good versions are for sure:<br />
<br />
Version 4.00.001 Jun 27 1996<br />
<br />
and<br />
<br />
Version 4.00.010 Apr 26 1999 <br />
<br />
which is essentially the same version as the above with some fixes done specifically for the Mozilla team. It was available at:<br />
<br />
ftp://ftp.software.ibm.com/ps/products/warpzilla/os2tk40rc.zip<br />
<br />
Finally, someone successfully replaced rc.exe from IBM with the one from the Open Watcom compiler, wrc.exe, that accepts much longer command lines.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
In case of problems, verify if x:\CVS\xworkplace\bin\full directory has been created. If not, create it.<br />
<br />
You have also good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4929Compiling XWP2007-12-19T11:42:21Z<p>Ggamba: /* Compiling the beast */</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
* Several versions of rc.exe are around, and not all of them work well for XWP compilation. Good versions are for sure:<br />
<br />
Version 4.00.001 Jun 27 1996<br />
<br />
and<br />
<br />
Version 4.00.010 Apr 26 1999 <br />
<br />
which is essentially the same version as the above with some fixes done specifically for the Mozilla team. It was available at:<br />
<br />
ftp://ftp.software.ibm.com/ps/products/warpzilla/os2tk40rc.zip<br />
<br />
Finally, someone successfully replaced rc.exe from IBM with the one from the Open Watcom compiler, wrc.exe, that accepts much longer command lines.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
In case of problems, verify that x:\CVS\xworkplace\bin\full directory has been created. If not, create it.<br />
<br />
You have also good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4928Compiling XWP2007-12-19T11:41:55Z<p>Ggamba: Note about creation of \bin\full directory</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
* Several versions of rc.exe are around, and not all of them work well for XWP compilation. Good versions are for sure:<br />
<br />
Version 4.00.001 Jun 27 1996<br />
<br />
and<br />
<br />
Version 4.00.010 Apr 26 1999 <br />
<br />
which is essentially the same version as the above with some fixes done specifically for the Mozilla team. It was available at:<br />
<br />
ftp://ftp.software.ibm.com/ps/products/warpzilla/os2tk40rc.zip<br />
<br />
Finally, someone successfully replaced rc.exe from IBM with the one from the Open Watcom compiler, wrc.exe, that accepts much longer command lines.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
In case of problems, verify that x:\CVS\xworkplace\bin\full has been created. If not, create it.<br />
<br />
You have also good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4542Compiling XWP2007-03-29T09:45:15Z<p>Ggamba: Note about rc.exe</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
* Several versions of rc.exe are around, and not all of them work well for XWP compilation. Good versions are for sure:<br />
<br />
Version 4.00.001 Jun 27 1996<br />
<br />
and<br />
<br />
Version 4.00.010 Apr 26 1999 <br />
<br />
which is essentially the same version as the above with some fixes done specifically for the Mozilla team. It was available at:<br />
<br />
ftp://ftp.software.ibm.com/ps/products/warpzilla/os2tk40rc.zip<br />
<br />
Finally, someone successfully replaced rc.exe from IBM with the one from the Open Watcom compiler, wrc.exe, that accepts much longer command lines.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4411Compiling XWP2007-01-20T16:56:53Z<p>Ggamba: www.netlabs.org -> cvs.netlabs.org</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@cvs.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4390Compiling XWP2007-01-11T13:16:00Z<p>Ggamba: Updated translators section</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources. Special thanks to Steven Levine for reviewing, correcting and enhancing the text''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(xwphelpers repository doesn't have "sandboxes" as there is nothing inside NLS-related). <br />
Taking XWorkplace version 1.0.7 as sample: I copy the \xworkplace_branch directory as \xworkplace_107, then do:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0005_1-0-7<br />
<br />
in \xworkplace_107 and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0016_xwp1-0-7<br />
<br />
in the XWP helpers directory. Since you can not commit changes if you have checked out a release, it is necessary to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
I can now compare (with [http://www.ecomstation.it/ecsoft2/prog.php?progid=827 ddiff] and [http://www.ecomstation.it/ecsoft2/prog.php?progid=1370 kdiff]) \xworkplace_107\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_107\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_107\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0003-1-0-7<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4389Compiling XWP2007-01-11T10:13:10Z<p>Ggamba: updated tags for 1.0.7</p>
<hr />
<div>[[Category:Projects]]<br />
''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.7''' (the latest released version):<br />
<br />
cvs checkout -r pr_0005_1-0-7 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0016_xwp1-0-7 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(I don't need different "sandboxes" of xwphelpers repositories). I routinely update the branch. When version xyz of XWP is released, I copy the \xworkplace_branch directory as \xworkplace_xyz, then do:<br />
<br />
cd \xwp_work<br />
set R=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
cvs -d %R% checkout -r pr_0002-1-0-4 .<br />
cd 039<br />
cvs update -A -r branch-1-0<br />
<br />
This way I check out XWP sources using the release tag while keeping the Italian NLS subdirectory tree at branch level.<br />
<br />
I then compare (with ddiff and gfc) \xworkplace_xyz\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_xyz\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_xyz\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0002-1-0-6<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.<br />
<br />
===Checkouts for translators (SHL version) ===<br />
<br />
Since you can not commit changes if you have checked out a release, translators need to do a bit of extra work to set up their sandboxes. They need to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
To does this for the '''1.0.6 release''', use:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0004_1-0-6<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4270Compiling XWP2006-12-10T10:29:19Z<p>Ggamba: /* Compiling the beast */</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.6''' (the latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0015_xwp1-0-6 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(I don't need different "sandboxes" of xwphelpers repositories). I routinely update the branch. When version xyz of XWP is released, I copy the \xworkplace_branch directory as \xworkplace_xyz, then do:<br />
<br />
cd \xwp_work<br />
set R=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
cvs -d %R% checkout -r pr_0002-1-0-4 .<br />
cd 039<br />
cvs update -A -r branch-1-0<br />
<br />
This way I check out XWP sources using the release tag while keeping the Italian NLS subdirectory tree at branch level.<br />
<br />
I then compare (with ddiff and gfc) \xworkplace_xyz\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_xyz\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_xyz\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0002-1-0-6<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.<br />
<br />
===Checkouts for translators (SHL version) ===<br />
<br />
Since you can not commit changes if you have checked out a release, translators need to do a bit of extra work to set up their sandboxes. They need to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
To does this for the '''1.0.6 release''', use:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0004_1-0-6<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4269Compiling XWP2006-12-10T10:28:50Z<p>Ggamba: /* Branch, trunk, tags... */ missing dots!</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve both the XWP Sources and XWP Helpers from the Netlabs' CVS server.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) Create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
This is the location of the XWP Sources repository at Netlabs.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded for this repository.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This command will retrieve the most recent XWP sources from the CVS repository for the XWP 1.x branch into the current subdirectory. Cvs calls subdirectory tree and its contents a ''sandbox''. More on branches and tags below.<br />
<br />
Now you need to retrieve the XWP helpers:<br />
<br />
1) First, do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
This is the location of the XWP Helpers repository.<br />
<br />
2) Create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to this subdirectory.<br />
<br />
3) If this is first time you have used the XWP Sources respository, you need to log in. Do:<br />
<br />
SET USER=guest<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password. Cvs remembers your login information in %HOME%\.cvspass, so you only need to login if this information is not already recorded.<br />
<br />
4) Do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You have now downloaded all the files you need to compile the latest XWP branch stuff.<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with the trunk, or compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for each version you are working with. This will save you time. A good directory organization could be:<br />
<br />
* Your CVS root folder <br />
** XWP Sources branch<br />
** XWP Sources trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
If disk space is a problem, you can use a single set of sandboxes and switch the sandbox content as needed. More on this below.<br />
<br />
To checkout the '''trunk''', checkout with no tag using:<br />
<br />
cvs checkout .<br />
<br />
in both the XWP Sources and the XWP Helpers sandbox directories.<br />
<br />
To checkout the '''1.0 branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
in the XWP sources and the XWP helpers sandbox directories.<br />
<br />
To checkout '''version 1.0.6''' (the latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6 .<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r pr_0015_xwp1-0-6 .<br />
<br />
in the XWP helpers directory.<br />
<br />
Once you have done an initial checkout from CVS, you can use the ''cvs status -v filename'' command to determine which tags exist. For example, run:<br />
<br />
cvs status -v -l makefile <br />
<br />
from the x:\cvs\xworkplace directory to see the existing tags for the XWorkplace package. This works because the developers always tag makefile for every release even if this file has not changed.<br />
<br />
All the above samples are for an intiial checkout from the CVS server. This means that you are downloading from CVS into an empty directory.<br />
<br />
Once you have done an initial checkout of a branch or the trunk, you usually want to use the "update" command to download files modified by others instead of the "checkout" command. The update command is faster than the checkout command because it generally does a lot less work. Run the command:<br />
<br />
cvs upd<br />
<br />
in each subdirectory to be updated. It is safe to use this command even if you have changes in progress. Cvs will not overwrite your uncommited changes.<br />
<br />
When working with an existing sandbox, there's no need to set CVSROOT or USER. Cvs records this data in control files within the sandbox.<br />
<br />
You can switch the content of an existing sandbox to a different release or branch.<br />
To switch your sandbox directories to the 1.0.6 release, the commands would be:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
in the XWP sources directory and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.<br />
<br />
Tags can be confusing to those new to CVS. There are revision tags and branch tags. They often look the same, but they do not work the same. A revision tag refers to a specific file. A branch tag refers to the newest file on the branch. XWP releases are tagged with revision tags.<br />
<br />
If you checkout using a revision tag, you can not commit changes. If you checkout using a branch tag, you can commit changes, if you have permission to do commits. The trunk is effectively an unnamed branch. The XWP naming convention is that branch tags always contain the word branch in the tag name. If you are not sure if a tag is a branch tag or a revision tag, use the cvs status command.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good. If you are using some other Toolkit, be sure to backlevel emitc.dll to the OS/2 Warp 4.0 Toolkit version.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good chance to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN. It's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take only branch diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do the diffs for the XWP Helpers as well if you modify something there.<br />
<br />
===Notes for translators===<br />
<br />
As a sample for people interested in translating XWP to their own language, here is explained how the Italian translation of XWP is maintained.<br />
The following is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(I don't need different "sandboxes" of xwphelpers repositories). I routinely update the branch. When version xyz of XWP is released, I copy the \xworkplace_branch directory as \xworkplace_xyz, then do:<br />
<br />
cd \xwp_work<br />
set R=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
cvs -d %R% checkout -r pr_0002-1-0-4 .<br />
cd 039<br />
cvs update -A -r branch-1-0<br />
<br />
This way I check out XWP sources using the release tag while keeping the Italian NLS subdirectory tree at branch level.<br />
<br />
I then compare (with ddiff and gfc) \xworkplace_xyz\001 directory with the content of \xworkplace_branch\001, and update \xworkplace_xyz\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_xyz\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0002-1-0-6<br />
<br />
If I need to make some additional updates, this tag allows me to recreate the sandbox.<br />
<br />
Finally, after editing the config.in file in the appropriate way, I compile the translated resource with the command:<br />
<br />
nmake nls<br />
<br />
In addition, "nmake wpi_nls" will create the archive in the release directory.<br />
<br />
===Checkouts for translators (SHL version) ===<br />
<br />
Since you can not commit changes if you have checked out a release, translators need to do a bit of extra work to set up their sandboxes. They need to checkout the branch and then backout any changes that were made since the version was released.<br />
<br />
To does this for the '''1.0.6 release''', use:<br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0004_1-0-6<br />
<br />
in the XWP sources directory and <br />
<br />
cvs checkout -r branch-1-0 .<br />
cvs update -j pr_0015_xwp1-0-6<br />
<br />
in the XWP helpers directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4266Compiling XWP2006-12-09T15:51:28Z<p>Ggamba: /* Branch, trunk, tags... */</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
2) create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to it and do:<br />
<br />
SET USER=guest<br />
<br />
3) from the same directory, do:<br />
<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password;<br />
<br />
4) do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need to retrieve the XWorkplace helpers:<br />
<br />
1) go again in your CVS root folder (e.g. x:\CVS) and do:<br />
<br />
CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
2) create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to xwphelpers and do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You just downloaded from CVS all what you need to compile the latest XWP branch stuff!<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
To checkout the '''trunk''', use no tag:<br />
<br />
cvs checkout .<br />
<br />
both for xwp and xwp helpers.<br />
<br />
To checkout the '''branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
again both for xwp and xwp helpers. To checkout '''version 1.0.6''' (latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6<br />
<br />
in xworkplace directory and <br />
<br />
cvs checkout -r pr_0015_xwp1-0-6<br />
<br />
in the xwphelpers one. Once the first checkout from CVS is done, the ''cvs status -v filename'' command will tell you which tag exist; for example, running:<br />
<br />
cvs status -v makefile <br />
<br />
from the x:\cvs\xworkplace directory will tell you which are the existing tags for the XWorkplace package.<br />
<br />
All the above samples are to checkout from the CVS server, that means that you are importing from CVS from scratch, in an empty directory. <br />
<br />
Since you have done a checkout, you can use the "update" command instead that the "checkout" one. The last sample would become:<br />
<br />
cvs upd -A -r pr_0004_1-0-6<br />
<br />
and<br />
<br />
cvs upd -A -r pr_0015_xwp1-0-6<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take branch only diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do it for the Helpers as well if you modify something there.<br />
<br />
<br />
===Notes for translators===<br />
As a sample for people interested in translate XWP to his own language, here is explained how the Italian translation of XWP is maintained.<br />
The following one is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(I don't need different "sandboxes" of xwphelpers repository). I routinely update the branch. When version xyz of XWP is released, I copy the \xworkplace_branch directory as \xworkplace_xyz, then do:<br />
<br />
cd \xwp_work<br />
set R=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
cvs -d %R% checkout -r pr_0002-1-0-4 .<br />
cd 039<br />
cvs update -A -r branch-1-0<br />
<br />
In this way I checkout XWP sources using the release tag while keeping Italian NLS subdirectory tree at branch level.<br />
<br />
I then compare (with ddiff and gfc) \xworkplace_xyz\001 directory with content of \xworkplace_branch\001, and update \xworkplace_xyz\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_xyz\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0002-1-0-6<br />
<br />
If I need to make some follow on updates, this tag allow me to recreate the sandbox.<br />
<br />
Finally, after editing config.in file in the appropriate way, with the command:<br />
<br />
nmake nls<br />
<br />
I compile the translated resources. In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4265Compiling XWP2006-12-09T15:49:20Z<p>Ggamba: /* Notes for translators */</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
2) create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to it and do:<br />
<br />
SET USER=guest<br />
<br />
3) from the same directory, do:<br />
<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password;<br />
<br />
4) do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need to retrieve the XWorkplace helpers:<br />
<br />
1) go again in your CVS root folder (e.g. x:\CVS) and do:<br />
<br />
CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
2) create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to xwphelpers and do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You just downloaded from CVS all what you need to compile the latest XWP branch stuff!<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
To checkout the '''trunk''', use no tag:<br />
<br />
cvs checkout .<br />
<br />
both for xwp and xwp helpers.<br />
<br />
To checkout the '''branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
again both for xwp and xwp helpers. To checkout '''version 1.0.6''' (latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6<br />
<br />
in xworkplace directory and <br />
<br />
cvs checkout -r pr_0015_xwp1-0-6<br />
<br />
in the xwphelpers one. Once the first checkout from CVS is done, the ''cvs status -v filename'' command will tell you which tag exist; for example, running:<br />
<br />
cvs status -v makefile <br />
<br />
from the x:\cvs\xworkplace directory will tell you which are the existing tags for the XWorkplace package.<br />
<br />
All the above samples are to checkout from the CVS server, that means that you are importing from CVS from scratch, in an empty directory. <br />
<br />
Since you have done a checkout, you can use the "update" command instead that the "checkout" one. The last sample would become:<br />
<br />
cvs upd -A -rpr_0004_1-0-6<br />
<br />
and<br />
<br />
cvs upd -A -rpr_0015_xwp1-0-6<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take branch only diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do it for the Helpers as well if you modify something there.<br />
<br />
<br />
===Notes for translators===<br />
As a sample for people interested in translate XWP to his own language, here is explained how the Italian translation of XWP is maintained.<br />
The following one is the folder structure I use:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(I don't need different "sandboxes" of xwphelpers repository). I routinely update the branch. When version xyz of XWP is released, I copy the \xworkplace_branch directory as \xworkplace_xyz, then do:<br />
<br />
cd \xwp_work<br />
set R=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
cvs -d %R% checkout -r pr_0002-1-0-4 .<br />
cd 039<br />
cvs update -A -r branch-1-0<br />
<br />
In this way I checkout XWP sources using the release tag while keeping Italian NLS subdirectory tree at branch level.<br />
<br />
I then compare (with ddiff and gfc) \xworkplace_xyz\001 directory with content of \xworkplace_branch\001, and update \xworkplace_xyz\039 as needed. Once everything has been updated and tested, I commit my changes with <br />
<br />
cvs commit<br />
<br />
from \xworkplace_xyz\039 directory and then, from the same directory, create a release tag for the Italian NLS subdirectory tree:<br />
<br />
cvs tag ggamba_0002-1-0-6<br />
<br />
If I need to make some follow on updates, this tag allow me to recreate the sandbox.<br />
<br />
Finally, after editing config.in file in the appropriate way, with the command:<br />
<br />
nmake nls<br />
<br />
I compile the translated resources. In addition, "nmake wpi_nls" will create the archive in the release directory.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4264Compiling XWP2006-12-09T15:28:45Z<p>Ggamba: create diff files</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
2) create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to it and do:<br />
<br />
SET USER=guest<br />
<br />
3) from the same directory, do:<br />
<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password;<br />
<br />
4) do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need to retrieve the XWorkplace helpers:<br />
<br />
1) go again in your CVS root folder (e.g. x:\CVS) and do:<br />
<br />
CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
2) create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to xwphelpers and do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You just downloaded from CVS all what you need to compile the latest XWP branch stuff!<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
To checkout the '''trunk''', use no tag:<br />
<br />
cvs checkout .<br />
<br />
both for xwp and xwp helpers.<br />
<br />
To checkout the '''branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
again both for xwp and xwp helpers. To checkout '''version 1.0.6''' (latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6<br />
<br />
in xworkplace directory and <br />
<br />
cvs checkout -r pr_0015_xwp1-0-6<br />
<br />
in the xwphelpers one. Once the first checkout from CVS is done, the ''cvs status -v filename'' command will tell you which tag exist; for example, running:<br />
<br />
cvs status -v makefile <br />
<br />
from the x:\cvs\xworkplace directory will tell you which are the existing tags for the XWorkplace package.<br />
<br />
All the above samples are to checkout from the CVS server, that means that you are importing from CVS from scratch, in an empty directory. <br />
<br />
Since you have done a checkout, you can use the "update" command instead that the "checkout" one. The last sample would become:<br />
<br />
cvs upd -A -rpr_0004_1-0-6<br />
<br />
and<br />
<br />
cvs upd -A -rpr_0015_xwp1-0-6<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
<br />
==Notes for contributors==<br />
<br />
If you modify something in the source and you want to send the developer the diffs, you can easily create them with CVS with the following command:<br />
<br />
cvs -z3 diff -u >description_of_changes.diff<br />
<br />
from the root of the sandbox is my preference. gnupatch will accept these<br />
without issues. Attach the .diff file in an email and send it to Paul Ratcliffe, the code maintainer.<br />
<br />
You should ideally do this for both the branch and the trunk, but currently Paul will take branch only diffs. Often they will be the same anyway.<br />
<br />
You need to remember to do it for the Helpers as well if you modify something there.<br />
<br />
<br />
===Notes for translators===<br />
As told before, we need different "sandboxes" for the different XWP releases.<br />
The following one, for example, is the folder structure I use for the Italian translation of XWP:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(to build the NLS package, I don't need "sandboxes" of xwphelpers repository)</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4263Compiling XWP2006-12-09T15:15:50Z<p>Ggamba: /* Branch, trunk, tags... */</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
2) create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to it and do:<br />
<br />
SET USER=guest<br />
<br />
3) from the same directory, do:<br />
<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password;<br />
<br />
4) do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need to retrieve the XWorkplace helpers:<br />
<br />
1) go again in your CVS root folder (e.g. x:\CVS) and do:<br />
<br />
CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
2) create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to xwphelpers and do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You just downloaded from CVS all what you need to compile the latest XWP branch stuff!<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
To checkout the '''trunk''', use no tag:<br />
<br />
cvs checkout .<br />
<br />
both for xwp and xwp helpers.<br />
<br />
To checkout the '''branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
again both for xwp and xwp helpers. To checkout '''version 1.0.6''' (latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6<br />
<br />
in xworkplace directory and <br />
<br />
cvs checkout -r pr_0015_xwp1-0-6<br />
<br />
in the xwphelpers one. Once the first checkout from CVS is done, the ''cvs status -v filename'' command will tell you which tag exist; for example, running:<br />
<br />
cvs status -v makefile <br />
<br />
from the x:\cvs\xworkplace directory will tell you which are the existing tags for the XWorkplace package.<br />
<br />
All the above samples are to checkout from the CVS server, that means that you are importing from CVS from scratch, in an empty directory. <br />
<br />
Since you have done a checkout, you can use the "update" command instead that the "checkout" one. The last sample would become:<br />
<br />
cvs upd -A -rpr_0004_1-0-6<br />
<br />
and<br />
<br />
cvs upd -A -rpr_0015_xwp1-0-6<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
<br />
==Notes for contributors==<br />
<br />
<br />
===Notes for translators===<br />
As told before, we need different "sandboxes" for the different XWP releases.<br />
The following one, for example, is the folder structure I use for the Italian translation of XWP:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(to build the NLS package, I don't need "sandboxes" of xwphelpers repository)</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4262Compiling XWP2006-12-09T15:09:44Z<p>Ggamba: /* Branch, trunk, tags... */</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
2) create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to it and do:<br />
<br />
SET USER=guest<br />
<br />
3) from the same directory, do:<br />
<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password;<br />
<br />
4) do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need to retrieve the XWorkplace helpers:<br />
<br />
1) go again in your CVS root folder (e.g. x:\CVS) and do:<br />
<br />
CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
2) create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to xwphelpers and do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You just downloaded from CVS all what you need to compile the latest XWP branch stuff!<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
To checkout the '''trunk''', use no tag:<br />
<br />
cvs checkout .<br />
<br />
both for xwp and xwp helpers.<br />
<br />
To checkout the '''branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
again both for xwp and xwp helpers. To checkout version 1.0.6 (latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6<br />
<br />
in xworkplace directory and <br />
<br />
cvs checkout -r pr_0015_xwp1-0-6<br />
<br />
in the xwphelpers one. Once the first checkout from CVS is done, the ''cvs status -v filename'' command you can easily see which tag exist; for example, running:<br />
<br />
cvs status -v makefile<br />
<br />
from the x:\cvs\xworkplace directory will tell you which are the existing tags for the XWorkplace package.<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
<br />
==Notes for contributors==<br />
<br />
<br />
===Notes for translators===<br />
As told before, we need different "sandboxes" for the different XWP releases.<br />
The following one, for example, is the folder structure I use for the Italian translation of XWP:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(to build the NLS package, I don't need "sandboxes" of xwphelpers repository)</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4261Compiling XWP2006-12-09T15:07:16Z<p>Ggamba: </p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
2) create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to it and do:<br />
<br />
SET USER=guest<br />
<br />
3) from the same directory, do:<br />
<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password;<br />
<br />
4) do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need to retrieve the XWorkplace helpers:<br />
<br />
1) go again in your CVS root folder (e.g. x:\CVS) and do:<br />
<br />
CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
2) create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to xwphelpers and do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You just downloaded from CVS all what you need to compile the latest XWP branch stuff!<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
To checkout the '''trunk''', use no tag:<br />
<br />
cvs checkout .<br />
<br />
both for xwp and xwp helpers.<br />
<br />
To checkout the '''branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
again both for xwp and xwp helpers. To checkout version 1.0.6 (latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6<br />
<br />
Once the first checkout from CVS is done, the ''cvs status -v filename'' command you can easily see which tag exist; for example, running:<br />
<br />
cvs status -v makefile<br />
<br />
from the x:\cvs\xworkplace directory will tell you which are the existing tags for the XWorkplace package.<br />
<br />
<br />
<br />
== Compiling the beast ==<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is recommended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to compile XWP.<br />
<br />
1) first of all, adjust x:\CVS\xworkplace\config.in to your needs;<br />
2) then, from x:\CVS\xworkplace\ run <br />
<br />
nmake dep<br />
<br />
If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
<br />
3) After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
<br />
==Notes for contributors==<br />
<br />
<br />
===Notes for translators===<br />
As told before, we need different "sandboxes" for the different XWP releases.<br />
The following one, for example, is the folder structure I use for the Italian translation of XWP:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(to build the NLS package, I don't need "sandboxes" of xwphelpers repository)</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4258Compiling XWP2006-12-09T14:59:50Z<p>Ggamba: reordered paragraph</p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
== Getting sources from CVS ==<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
1) create the CVS root folder (e.g. x:\CVS) and then do:<br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
2) create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace), change to it and do:<br />
<br />
SET USER=guest<br />
<br />
3) from the same directory, do:<br />
<br />
CVS login<br />
<br />
and enter "readonly" when you are prompted for password;<br />
<br />
4) do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need to retrieve the XWorkplace helpers:<br />
<br />
1) go again in your CVS root folder (e.g. x:\CVS) and do:<br />
<br />
CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers<br />
<br />
2) create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers), change to xwphelpers and do:<br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
You just downloaded from CVS all what you need to compile the latest XWP branch stuff!<br />
<br />
<br />
===Branch, trunk, tags...===<br />
<br />
As you sooner or later will like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
<br />
To checkout the '''trunk''', use no tag:<br />
<br />
cvs checkout .<br />
<br />
both for xwp and xwp helpers.<br />
<br />
To checkout the '''branch''', use the "branch-1-0" tag:<br />
<br />
cvs checkout -r branch-1-0 .<br />
<br />
again both for xwp and xwp helpers. To checkout version 1.0.6 (latest released version):<br />
<br />
cvs checkout -r pr_0004_1-0-6<br />
<br />
=== The compilation environment ===<br />
<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
===Notes for contributors===<br />
<br />
<br />
===Notes for translators===<br />
As told before, we need different "sandboxes" for the different XWP releases.<br />
The following one, for example, is the folder structure I use for the Italian translation of XWP:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(to build the NLS package, I don't need "sandboxes" of xwphelpers repository)</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4255Compiling XWP2006-12-09T14:34:45Z<p>Ggamba: </p>
<hr />
<div>''Please note that this is not the "official" how-to, but just a collection of suggestions an tips harvested from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS and from the XWP mailing lists. The "official" how-to remains the progref.inf file included in the XWP's sources.''<br />
<br />
----<br />
<br />
=== Getting sources from CVS ===<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a [http://www.xworkplace.org/cvs.html working CVS setup], do this:<br />
<br />
* go in your CVS root folder (e.g. x:\CVS)<br />
* do <br />
<br />
SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace<br />
<br />
* create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace)<br />
* change to xworkplace directory and do<br />
<br />
SET USER=guest<br />
<br />
* from the same directory, do <br />
<br />
CVS login<br />
<br />
enter "readonly" when you are prompted for password<br />
* do <br />
<br />
cvs checkout -r '''branch-1-0''' .<br />
<br />
Don't forget the last dot! This last command will retrieve the most updated stuff from CVS.<br />
<br />
Now you need the XWorkplace helpers.<br />
<br />
* go again in your CVS root folder (e.g. x:\CVS)<br />
* do "CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers"<br />
* create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers)<br />
* change to xwphelpers and do "cvs checkout -r '''branch-1-0''' ."<br />
<br />
You just downloaded from CVS all what you need to compile the very latest XWP branch stuff. As you sooner or later could like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
** WarpIn<br />
<br />
XWP branch requires the XWP Helpers branch, XWP trunk requires the XWP Helpers trunk and WarpIn, just as a note, requires the XWP Helpers trunk. <br />
<br />
<br />
* To checkout the '''trunk''', use no tag, that is: "cvs checkout ."<br />
* To checkout the '''branches''', use the "branch-1-0" tag: "cvs checkout -r branch-1-0 ."<br />
* If you want to build '''latest public version''' then checkout using the release tags, that is for XWP: "cvs checkout -r pr_0002_1-0-4 ." and for XWP Helpers: "cvs checkout -r pr_0007_xwp1-0-4 ."<br />
If you want to modify (NLS) things, then checkout using the branch tag. You ought to set your own release tags for the NLS stuff when you are done.<br />
<br />
<br />
<br />
<br />
=== The compilation environment ===<br />
<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.<br />
<br />
<br />
===Notes for contributors===<br />
<br />
<br />
===Notes for translators===<br />
As told before, we need different "sandboxes" for the different XWP releases.<br />
The following one, for example, is the folder structure I use for the Italian translation of XWP:<br />
<br />
\Netlabs_CVS<br />
\Netlabs_CVS\xwphelpers<br />
\Netlabs_CVS\xworkplace_branch<br />
\Netlabs_CVS\xworkplace_105<br />
\Netlabs_CVS\xworkplace_106<br />
<br />
(to build the NLS package, I don't need "sandboxes" of xwphelpers repository)</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4212Configuring imapd server port2006-11-02T16:14:37Z<p>Ggamba: </p>
<hr />
<div>== How to install and configure the port of IMAP server for Os/2 ==<br />
<br />
- Download the IMAP server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere;<br />
<br />
- create a directory to store the INBOX files for all the users, for example ''c:\var\mail'', and one directory for each user, for example ''c:\home\default\mail\username'';<br />
<br />
- in \MPTN\ETC create an empty file named '''passwd''' and add to the '''inetd.lst''' file (create it if missing) the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup (in \TCPIP\BIN\tcpstart.cmd)<br />
<br />
- run the command '''pw2add''' for each user; user name will be ''username'' as in ''c:\home\default\mail\username'' and password will be what you like (it is just to connect to the local imapd server); home directory will be ''c:\home\default\mail\username'';<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location;<br />
<br />
- for each user, run <br />
<br />
mailutil create "#driver.mbx/c:\var\mail\username"<br />
<br />
then start inetd. Note: '''don't''' run inetd from the same directory where imapd.exe is! If you look at the window where inetd is running, for any imapd command received you should see only a single line like: <br />
<br />
spawnning imapd socket=xxxx<br />
<br />
Server is up and running! Above configuration was tested with both Thunderbird and Squirrelmail. If you connect with Thunderbird, you must turn off the use of the "IDLE" command. You can turn off idle by de-selecting "Use IDLE command" in Thunderbird's advanced settings box of your e-mail account's server settings.<br />
<br />
== Folders within other folders ==<br />
<br />
For what I was able to understand, Inbox can't contain subfolders, nor can Trash, Sent or Drafts folders, while folders created by users can contain other folders within them, but not messages.<br />
<br />
Creating folders within folders requires manual intervention on the server. Imagine you just started the server and connected with an IMAP client. In ''c:\home\default\mail\username'' you will have the following files:<br />
<br />
Drafts<br />
Sent<br />
Trash <br />
mailbox.lst<br />
<br />
To have a "Friends" folder containing subfolders, you need to <br />
<br />
- manually create ''c:\home\default\mail\username\Friends'' folder and<br />
<br />
- add ''Friends'' to mailbox.lst file<br />
<br />
Then, with Thunderbird you will be able to create subfolders in "Friends" folder. Selecting "Friends" you will get an error message: <br />
<br />
SELECT failed: permissione denied: Friends<br />
<br />
but opening the menu you can safely choose "New subfolder...". '''Note''': you will not be able to move messages into "Friends", but will be able to move messages to "Friends" subfolder(s). I'm currently not able to delete folders from Thunderbird: you will have to do that manually.<br />
<br />
I'm still trying to understand how to automatically fetch mail from external pop servers and append to the INBOX file.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4211Configuring imapd server port2006-11-02T16:13:54Z<p>Ggamba: /* How to install and configure the port of IMAP server for Os/2 */</p>
<hr />
<div>== How to install and configure the port of IMAP server for Os/2 ==<br />
<br />
- Download the IMAP server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere;<br />
<br />
- create a directory to store the INBOX files for all the users, for example ''c:\var\mail'', and one directory for each user, for example ''c:\home\default\mail\username'';<br />
<br />
- in \MPTN\ETC create an empty file named '''passwd''' and add to the '''inetd.lst''' file (create it if missing) the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup (in \TCPIP\BIN\tcpstart.cmd)<br />
<br />
- run the command '''pw2add''' for each user; user name will be ''username'' as in ''c:\home\default\mail\username'' and password will be what you like (it is just to connect to the local imapd server); home directory will be ''c:\home\default\mail\username'';<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location;<br />
<br />
- for each user, run <br />
<br />
mailutil create "#driver.mbx/c:\var\mail\username"<br />
<br />
then start inetd. Note: '''don't''' run inetd from the same directory where imapd.exe is! If you look at the window where inetd is running, for any imapd command received you should see only a single line like: <br />
<br />
spawnning imapd socket=xxxx<br />
<br />
Server is up and running! Above configuration was tested with both Thunderbird and Squirrelmail. If you connect with Thunderbird, you must turn off the use of the "IDLE" command. You can turn off idle by de-selecting "Use IDLE command" in Thunderbird's advanced settings box of your e-mail account's server settings.<br />
<br />
== Folders within other folders ==<br />
<br />
For what I was able to understand, Inbox can't contain subfolders, nor can Trash, Sent or Drafts folders, while folders created by users can contain other folders within them, but not messages.<br />
<br />
Creating folders within folders requires manual intervention on the server. Imagine you just started the server and connected with an IMAP client. In ''c:\home\default\mail\username'' you will have the following files:<br />
<br />
Drafts<br />
Sent<br />
Trash <br />
mailbox.lst<br />
<br />
To have a "Friends" folder containing subfolders, you need to <br />
<br />
- manually create ''c:\home\default\mail\username\Friends'' folder and<br />
<br />
- add ''Friends'' to mailbox.lst file<br />
<br />
Then, with Thunderbird you will be able to create subfolders in "Friends" folder. Selecting "Friends" you will get an error message: <br />
<br />
SELECT failed: permissione denied: Friends<br />
<br />
but opening the menu you can safely choose "New subfolder...". '''Note''': you will not be able to move messages into "Friends", but will be able to move messages to "Friends" subfolder(s). I'm currently not able to delete folders from Thunderbird: you will have to do that manually.<br />
<br />
I'm still trying to understand how to automatically fetch mail from external pop servers and append them to the INBOX file.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4210Configuring imapd server port2006-11-02T12:52:48Z<p>Ggamba: </p>
<hr />
<div>== How to install and configure the port of Imapd server for Os/2 ==<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere;<br />
<br />
- create a directory to store the INBOX files for all the users, for example ''c:\var\mail'', and one directory for each user, for example ''c:\home\default\mail\username'';<br />
<br />
- in \MPTN\ETC create an empty file named '''passwd''' and add to the '''inetd.lst''' file (create it if missing) the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup (in \TCPIP\BIN\tcpstart.cmd)<br />
<br />
- run the command '''pw2add''' for each user; user name will be ''username'' as in ''c:\home\default\mail\username'' and password will be what you like (it is just to connect to the local imapd server); home directory will be ''c:\home\default\mail\username'';<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location;<br />
<br />
- for each user, run <br />
<br />
mailutil create "#driver.mbx/c:\var\mail\username"<br />
<br />
then start inetd. Note: '''don't''' run inetd from the same directory where imapd.exe is! If you look at the window where inetd is running, for any imapd command received you should see only a single line like: <br />
<br />
spawnning imapd socket=xxxx<br />
<br />
Server is up and running! Above configuration was tested with both Thunderbird and Squirrelmail. If you connect with Thunderbird, you must turn off the use of the "IDLE" command. You can turn off idle by de-selecting "Use IDLE command" in Thunderbird's advanced settings box of your e-mail account's server settings.<br />
<br />
== Folders within other folders ==<br />
<br />
For what I was able to understand, Inbox can't contain subfolders, nor can Trash, Sent or Drafts folders, while folders created by users can contain other folders within them, but not messages.<br />
<br />
Creating folders within folders requires manual intervention on the server. Imagine you just started the server and connected with an IMAP client. In ''c:\home\default\mail\username'' you will have the following files:<br />
<br />
Drafts<br />
Sent<br />
Trash <br />
mailbox.lst<br />
<br />
To have a "Friends" folder containing subfolders, you need to <br />
<br />
- manually create ''c:\home\default\mail\username\Friends'' folder and<br />
<br />
- add ''Friends'' to mailbox.lst file<br />
<br />
Then, with Thunderbird you will be able to create subfolders in "Friends" folder. Selecting "Friends" you will get an error message: <br />
<br />
SELECT failed: permissione denied: Friends<br />
<br />
but opening the menu you can safely choose "New subfolder...". '''Note''': you will not be able to move messages into "Friends", but will be able to move messages to "Friends" subfolder(s). I'm currently not able to delete folders from Thunderbird: you will have to do that manually.<br />
<br />
I'm still trying to understand how to automatically fetch mail from external pop servers and append them to the INBOX file.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4209Configuring imapd server port2006-11-02T12:51:31Z<p>Ggamba: note about subfolders</p>
<hr />
<div>== How to install and configure the port of Imapd server for Os/2 ==<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere;<br />
<br />
- create a directory to store the INBOX files for all the users, for example ''c:\var\mail'', and one directory for each user, for example ''c:\home\default\mail\username'';<br />
<br />
- in \MPTN\ETC create an empty file named '''passwd''' and add to the '''inetd.lst''' file (create it if missing) the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup (in \TCPIP\BIN\tcpstart.cmd)<br />
<br />
- run the command '''pw2add''' for each user; user name will be ''username'' as in ''c:\home\default\mail\username'' and password will be what you like (it is just to connect to the local imapd server); home directory will be ''c:\home\default\mail\username'';<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location;<br />
<br />
- for each user, run <br />
<br />
mailutil create "#driver.mbx/c:\var\mail\username"<br />
<br />
then start inetd. Note: '''don't''' run inetd from the same directory where imapd.exe is! If you look at the window where inetd is running, for any imapd command received you should see only a single line like: <br />
<br />
spawnning imapd socket=xxxx<br />
<br />
Server is up and running! If you connect with Thunderbird, you must turn off the use of the "IDLE" command. You can turn off idle by de-selecting "Use IDLE command" in Thunderbird's advanced settings box of your e-mail account's server settings.<br />
<br />
== Folders within other folders ==<br />
<br />
For what I was able to understand, Inbox can't contain subfolders, nor can Trash, Sent or Drafts folders, while folders created by users can contain other folders within them, but not messages.<br />
<br />
Creating folders within folders requires manual intervention on the server. Imagine you just started the server and connected with an IMAP client. In ''c:\home\default\mail\username'' you will have the following files:<br />
<br />
Drafts<br />
Sent<br />
Trash <br />
mailbox.lst<br />
<br />
To have a "Friends" folder containing subfolders, you need to <br />
<br />
- manually create ''c:\home\default\mail\username\Friends'' folder and<br />
<br />
- add ''Friends'' to mailbox.lst file<br />
<br />
Then, with Thunderbird you will be able to create subfolders in "Friends" folder. Selecting "Friends" you will get an error message: <br />
<br />
SELECT failed: permissione denied: Friends<br />
<br />
but opening the menu you can safely choose "New subfolder...". '''Note''': you will not be able to move messages into "Friends", but will be able to move messages to "Friends" subfolder(s). I'm currently not able to delete folders from Thunderbird: you will have to do that manually.<br />
<br />
I'm still trying to understand how to automatically fetch mail from external pop servers and append them to the INBOX file.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4208Configuring imapd server port2006-11-02T12:30:59Z<p>Ggamba: /* How to install and configure the port of Imapd server for Os/2 */</p>
<hr />
<div>== How to install and configure the port of Imapd server for Os/2 ==<br />
<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere;<br />
<br />
- create a directory to store the INBOX files for all the users, for example ''c:\var\mail'', and one directory for each user, for example ''c:\home\default\mail\username'';<br />
<br />
- in \MPTN\ETC create an empty file named '''passwd''' and add to the '''inetd.lst''' file (create it if missing) the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup (in \TCPIP\BIN\tcpstart.cmd)<br />
<br />
- run the command '''pw2add''' for each user; user name will be ''username'' as in ''c:\home\default\mail\username'' and password will be what you like (it is just to connect to the local imapd server); home directory will be '':\home\default\mail\username'';<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location;<br />
<br />
- run <br />
<br />
mailutil create "#driver.mbx/mail\username"<br />
<br />
and start inetd (*). Server is up and running! If you connect with Thunderbird, you must turn off the use of the "IDLE" command. You can turn off idle by de-selecting "Use IDLE command" in Thunderbird's advanced settings box of your e-mail account's server settings.<br />
<br />
<br />
(*) Note: '''don't''' run inetd from the same directory where imapd.exe is! If you look at the window where inetd is running, for any imapd command received you should see only a single line like: <br />
<br />
spawnning imapd socket=xxxx</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4207Configuring imapd server port2006-10-26T13:51:15Z<p>Ggamba: </p>
<hr />
<div>== How to install and configure the port of Imapd server for Os/2 ==<br />
<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere;<br />
<br />
- create a directory to store the email files for the user ''username'', for example c:\home\default\mail\username<br />
<br />
- in \MPTN\ETC create an empty file named '''passwd''' and add to the '''inetd.lst''' file (create it if missing) the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup (in \TCPIP\BIN\tcpstart.cmd)<br />
<br />
- run the command '''pw2add'''; user name will be ''username'' and password will be what you like (it is just to connect to the imapd server); when asked for home directory, specify the previously created one (in the sample: "c:\home\default\mail\username")<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location; comment the "set mailspool" line<br />
<br />
- run <br />
<br />
mailutil create "#driver.mbx/mail\username\inbox"<br />
<br />
and start inetd (*). Server is up and running! If you connect with Thunderbird, you must turn off the use of the "IDLE" command. You can turn off idle by de-selecting "Use IDLE command" in Thunderbird's advanced settings box of your e-mail account's server settings.<br />
<br />
<br />
(*) Note: '''don't''' run inetd from the same directory where imapd.exe is! If you look at the window where inetd is running, for any imapd command received you should see only a single line like: <br />
<br />
spawnning imapd socket=xxxx</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4206Configuring imapd server port2006-10-26T13:19:49Z<p>Ggamba: </p>
<hr />
<div>== A small how to to install and configure the port of Imapd server for Os/2 ==<br />
<br />
<br />
'''DRAFT and INCOMPLETE'''<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere<br />
<br />
- create a directory to store the email files, for example c:\home\default\mail\username<br />
<br />
- in \MPTN\ETC create an empty file named '''passwd''' and add to the '''inetd.lst''' file (create it if missing) the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup (in \TCPIP\BIN\tcpstart.cmd)<br />
<br />
- run the command '''pw2add''' and, when asked for home directory, specify the previously created one (in our sample: "c:\home\default\mail\username")<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location; comment the "set mailspool" line<br />
<br />
- run <br />
<br />
mailutil create "#driver.mbx/mail\username\inbox"<br />
<br />
and start inetd. Server is up and running!</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4205Configuring imapd server port2006-10-26T13:12:08Z<p>Ggamba: </p>
<hr />
<div>== A small how to to install and configure the port of Imapd server for Os/2 ==<br />
<br />
<br />
'''DRAFT and INCOMPLETE'''<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere<br />
<br />
- create a directory to store the email files, for example c:\home\default\mail\username<br />
<br />
- in \mptn\etc create an empty file named '''passwd''' and add to the '''inetd.lst''' file the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup<br />
<br />
- run the command '''pw2add''' and, when asked for home directory, specify the previously created one (in our sample: "c:\home\default\mail\username")<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it to reflect the imapd.exe location; comment the "set mailspool" line</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4204Configuring imapd server port2006-10-26T13:04:54Z<p>Ggamba: </p>
<hr />
<div>== A small how to to install and configure the port of Imapd server for Os/2 ==<br />
<br />
<br />
'''DRAFT and INCOMPLETE'''<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere<br />
<br />
- in \mptn\etc create an empty file named '''passwd''' and add to the '''inetd.lst''' file the line:<br />
<br />
imap tcp imapd<br />
<br />
- configure inetd for autostart at system startup<br />
<br />
- create a directory for the Inbox file (e.g.: \var\mail), and one for the other files (e.g.: \home\default\imap)<br />
<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4203Configuring imapd server port2006-10-26T12:57:09Z<p>Ggamba: </p>
<hr />
<div>== A small how to to install and configure the port of Imapd server for Os/2 ==<br />
<br />
<br />
'''DRAFT and INCOMPLETE'''<br />
<br />
- Download the imapd server from [http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=Washington+mail+servers&stype=all&sort=type&dir=%2F Hobbes] and unzip it somewhere<br />
- create a directory for the Inbox file (e.g.: \var\mail), and one for the other files (e.g.: \home\default\imap)<br />
- copy the file imap.cmd to \TCPIP\BIN and edit it</div>Ggambahttps://wiki.netlabs.org/index.php?title=Configuring_imapd_server_port&diff=4202Configuring imapd server port2006-10-26T12:44:12Z<p>Ggamba: </p>
<hr />
<div><br />
== A small how to to installa a configure the port of Imapd server for Os/2 ==</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=4177Compiling XWP2006-10-22T19:02:59Z<p>Ggamba: note about SYS0032</p>
<hr />
<div>Please note that this is just a draft that comes from a not-expert, so use at your risk!<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS, from information harvested in the XWP newsgroup and from suggestions received in the same place.<br />
<br />
<br />
----<br />
<br />
<br />
== Getting sources from CVS ==<br />
<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
* go in your CVS root folder (e.g. x:\CVS)<br />
* do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
* create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace)<br />
* change to xworkplace directory and do "SET USER=guest"<br />
* from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
* do "cvs checkout -r '''branch-1-0''' ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS.<br />
Now you need the XWorkplace helpers.<br />
<br />
* go again in your CVS root folder (e.g. x:\CVS)<br />
* do "CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers"<br />
* create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers)<br />
* change to xwphelpers and do "cvs checkout -r '''branch-1-0''' ."<br />
<br />
You just downloaded from CVS all what you need to compile the very latest XWP branch stuff. As you sooner or later could like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
** WarpIn<br />
<br />
XWP branch requires the XWP Helpers branch, XWP trunk requires the XWP Helpers trunk and WarpIn, just as a note, requires the XWP Helpers trunk. <br />
* To checkout the '''trunk''', use no tag, that is: "cvs checkout ."<br />
* To checkout the '''branches''', use the "branch-1-0" tag: "cvs checkout -r branch-1-0 ."<br />
* If you want to build '''latest public version''' then checkout using the release tags, that is for XWP: "cvs checkout -r pr_0002_1-0-4 ." and for XWP Helpers: "cvs checkout -r pr_0007_xwp1-0-4 ."<br />
If you want to modify (NLS) things, then checkout using the branch tag. You ought to set your own release tags for the NLS stuff when you are done.<br />
<br />
<br />
<br />
----<br />
<br />
<br />
== The compilation environment ==<br />
<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE and XWPHOOK.DLL while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.<br />
You have good change to get an error like:<br />
<br />
E:\netlabs_CVS\xworkplace\bin\modules\xwphook.dll => E:\programs\xworkplace\binxwphook.dll<br />
SYS0032: Process can't access file...<br />
<br />
This means that you have XWorkplace running and you have to UNLOCK the files first if you are copying over your running files. Put XWP_UNLOCK_MODULES = YES in CONFIG.IN - it's down near the bottom. The Unlock utility from the LxLite package is required.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=3888Compiling XWP2006-04-01T09:48:27Z<p>Ggamba: </p>
<hr />
<div>Please note that this is just a draft that comes from a not-expert, so use at your risk :-)<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS, from information harvested in the XWP newsgroup and from suggestions received in the same place.<br />
<br />
<br />
----<br />
<br />
<br />
== Getting sources from CVS ==<br />
<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
* go in your CVS root folder (e.g. x:\CVS)<br />
* do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
* create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace)<br />
* change to xworkplace directory and do "SET USER=guest"<br />
* from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
* do "cvs checkout -r '''branch-1-0''' ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS.<br />
Now you need the XWorkplace helpers.<br />
<br />
* go again in your CVS root folder (e.g. x:\CVS)<br />
* do "CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers"<br />
* create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers)<br />
* change to xwphelpers and do "cvs checkout -r '''branch-1-0''' ."<br />
<br />
You just downloaded from CVS all what you need to compile the very latest XWP branch stuff. As you sooner or later could like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
** WarpIn<br />
<br />
XWP branch requires the XWP Helpers branch, XWP trunk requires the XWP Helpers trunk and WarpIn, just as a note, requires the XWP Helpers trunk. <br />
* To checkout the '''trunk''', use no tag, that is: "cvs checkout ."<br />
* To checkout the '''branches''', use the "branch-1-0" tag: "cvs checkout -r branch-1-0 ."<br />
* If you want to build '''latest public version''' then checkout using the release tags, that is for XWP: "cvs checkout -r pr_0002_1-0-4 ." and for XWP Helpers: "cvs checkout -r pr_0007_xwp1-0-4 ."<br />
If you want to modify (NLS) things, then checkout using the branch tag. You ought to set your own release tags for the NLS stuff when you are done.<br />
<br />
<br />
<br />
----<br />
<br />
<br />
== The compilation environment ==<br />
<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE, and XWPHOOK.DLL , while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=3738Compiling XWP2006-01-17T12:07:43Z<p>Ggamba: Updated CVS stuff</p>
<hr />
<div>Please note that this is just a draft that comes from a not-expert, so use at your risk :-)<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources, from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS, from information harvested in the XWP newsgroup and from suggestions received in the same place.<br />
<br />
<br />
----<br />
<br />
<br />
== Getting sources from CVS ==<br />
<br />
<br />
To compile XWP you need to retrieve from Netlabs' CVS server both XWP and XWP helpers sources.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
* go in your CVS root folder (e.g. x:\CVS)<br />
* do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
* create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace)<br />
* change to xworkplace directory and do "SET USER=guest"<br />
* from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
* do "cvs checkout -r branch-1-0 ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS.<br />
Now you need the XWorkplace helpers.<br />
<br />
* go again in your CVS root folder (e.g. x:\CVS)<br />
* do "CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers"<br />
* create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers)<br />
* change to xwphelpers and do "cvs checkout -r branch-1-0 ."<br />
<br />
You just downloaded from CVS all what you need to compile the very latest XWP branch stuff. As you sooner or later could like to play with trunk, or to compile a specific XWP version, maybe because you are working on translating it, a good idea is to maintain different ''sandboxes'' for trunk and branches. A good directory organization could be:<br />
<br />
*your CVS root folder <br />
** XWP branch<br />
** XWP trunk<br />
** XWP Helpers branch<br />
** XWP Helpers trunk<br />
** WarpIn<br />
<br />
XWP branch requires the XWP Helpers branch, XWP trunk requires the XWP Helpers trunk and WarpIn, just as a note, requires the XWP Helpers trunk. <br />
* To checkout the trunk, use no tag, that is: "cvs checkout ."<br />
* To checkout the branches, use the "branch-1-0" tag: "cvs checkout -r branch-1-0 ."<br />
* If you want to build latest public version then checkout using the release tags, that is for XWP: "cvs checkout -r pr_0002_1-0-4 ." and for XWP Helpers: "cvs checkout -r pr_0007_xwp1-0-4 ."<br />
If you want to modify (NLS) things, then checkout using the branch tag. You ought to set your own release tags for the NLS stuff when you are done.<br />
<br />
<br />
<br />
----<br />
<br />
<br />
== The compilation environment ==<br />
<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE, and XWPHOOK.DLL , while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=3733Compiling XWP2006-01-13T10:59:31Z<p>Ggamba: </p>
<hr />
<div>Hi all,<br />
<br />
I'm Gabriele Gamba and I first of all want to say that I'm totally ignorant about programming! More: these instructions come from one that is currently '''not able''' to successfully compile XWorkplace on his computer, so... use at your risk :-)<br />
So, what follows is just a draft, that I hope someone more computer literated than me can correct and extend, and I will be very happy to let him the honours for this page :-)<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources and from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
* go in your CVS root folder (e.g. x:\CVS)<br />
* do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
* create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace)<br />
* change to xworkplace directory and do "SET USER=guest"<br />
* from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
* do "cvs checkout -r branch-1-0 ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS.<br />
Now you need the XWorkplace helpers.<br />
<br />
* go again in your CVS root folder (e.g. x:\CVS)<br />
* do "CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers"<br />
* create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers)<br />
* change to xwphelpers and do "cvs checkout -r branch-1-0 ."<br />
<br />
You just downloaded from CVS all what you need to compile the very latest XWP stuff. Now, the compilation environment:<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE, and XWPHOOK.DLL , while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=3732Compiling XWP2006-01-13T10:45:14Z<p>Ggamba: Just a draft, of doubtful utility</p>
<hr />
<div>Hi all,<br />
<br />
I'm Gabriele Gamba and I first of all what to say that I'm totally ignorant about programming! More: these instructions come from one that is currently '''not able''' to successfully compile XWorkplace on his computer, so... use at your risk :-)<br />
So, what follows is just a draft, that I hope someone more computer literated than me can correct and extend, and I will be very happy to let him the honours for this page :-)<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources and from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
* go in your CVS root folder (e.g. x:\CVS)<br />
* do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
* create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace)<br />
* change to xworkplace directory and do "SET USER=guest"<br />
* from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
* do "cvs checkout -r branch-1-0 ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS.<br />
Now you need the XWorkplace helpers.<br />
<br />
* go again in your CVS root folder (e.g. x:\CVS)<br />
* do "CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers"<br />
* create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers)<br />
* change to xwphelpers and do "cvs checkout -r branch-1-0 ."<br />
<br />
You just downloaded from CVS all what you need to compile the very latest XWP stuff. Now, the compilation environment:<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE, and XWPHOOK.DLL , while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=3731Compiling XWP2006-01-13T10:43:44Z<p>Ggamba: </p>
<hr />
<div>Hi all,<br />
<br />
I'm Gabriele Gamba and I first of all what to say that I'm totally ignorant about programming! So, what follows is just a draft, that I hope someone more computer literated than me can correct and extend, and I will be very happy to let him the honours for this page :-)<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources and from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
* go in your CVS root folder (e.g. x:\CVS)<br />
* do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
* create a subdirectory in your CVS root directory named "xworkplace" (e.g. x:\cvs\xworkplace)<br />
* change to xworkplace directory and do "SET USER=guest"<br />
* from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
* do "cvs checkout -r branch-1-0 ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS.<br />
Now you need the XWorkplace helpers.<br />
<br />
* go again in your CVS root folder (e.g. x:\CVS)<br />
* do "CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xwphelpers"<br />
* create a subdirectory in your CVS root directory named "xwphelpers" (e.g. x:\cvs\xwphelpers)<br />
* change to xwphelpers and do "cvs checkout -r branch-1-0 ."<br />
<br />
You just downloaded from CVS all what you need to compile the very latest XWP stuff. Now, the compilation environment:<br />
<br />
* IBM VisualAge C++ 3.0 with fixpak 8 is reccomended (and it is also the only environment currently supported.<br />
* OS/2 Developer's Toolkit for all the SOM header files and the SOM compiler: the ones included in eCS 1.2 CD #2 seems good.<br />
<br />
Now, you have on your computer all what is needed to ''try'' to compile XWP :-)<br />
<br />
* first of all, adjust x:\CVS\xworkplace\config.in to your needs<br />
* then, from x:\CVS\xworkplace\ run "nmake dep". If you have never built XWorkplace before, "nmake dep" will give you lots of warnings that headers could not be found. This is normal.<br />
* After that, run either "nmake all" or "nmake really_all". "nmake all" will only rebuild XFLDR.DLL, XWPDAEMN.EXE, and XWPHOOK.DLL , while "nmake really_all" will produce the full set of XWorkplace executables plus the NLS files.</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=3730Compiling XWP2006-01-13T10:21:45Z<p>Ggamba: </p>
<hr />
<div>Hi all,<br />
<br />
I'm Gabriele Gamba and I first of all what to say that I'm totally ignorant about programming! So, what follows is just a draft, that I hope someone more computer literated than me can correct and extend, and I will be very happy to let him the honours for this page :-)<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources and from [http://www.xworkplace.org/cvs.html Ulrich's page] about setting up CVS.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
* go in your CVS root folder (e.g. e:\CVS)<br />
* do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
* create a subdirectory in your CVS root directory named "xworkplace (e.g. E:\cvs\xworkplace)<br />
* change to xworkplace directory and do "SET USER=guest"<br />
* from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
* do "cvs checkout -r branch-1-0 ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS</div>Ggambahttps://wiki.netlabs.org/index.php?title=Compiling_XWP&diff=3729Compiling XWP2006-01-13T10:17:59Z<p>Ggamba: </p>
<hr />
<div>Hi all,<br />
<br />
I'm Gabriele Gamba and I first of all what to say that I'm totally ignorant about programming! So, what follows is just a draft, that I hope someone more computer literated than me can correct and extend, and I will be very happy to let him the honours for this page :-)<br />
<br />
Information listed here comes from progref.inf file included in the XWP's sources and from http://www.xworkplace.org/cvs.html page.<br />
<br />
Supposing that you already have a working CVS setup, do this:<br />
<br />
1) go in your CVS root folder (e.g. e:\CVS)<br />
2) do "SET CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/xworkplace"<br />
3) create a subdirectory in your CVS root directory named "xworkplace (e.g. E:\cvs\xworkplace)<br />
4) change to xworkplace directory and do "SET USER=guest"<br />
5) from the same directory, do "CVS login"; enter "readonly" when you are prompted for password<br />
6) do "cvs checkout -r branch-1-0 ." <-- don't forget the last dot!<br />
<br />
This last command will retrieve the most updated stuff from CVS</div>Ggambahttps://wiki.netlabs.org/index.php?title=XWorkplace&diff=2403XWorkplace2005-09-25T16:33:13Z<p>Ggamba: /* XWorkplace: Ideas */</p>
<hr />
<div>=== XWorkplace: Future plan ===<br />
<br />
This page is intended to discuss future updates or additions to XWP.<br />
<br />
* Create a logoff feature, which basicly does everything shutdown does, but afterwards exits the [[WPS]], like with restart WPS, instead of shutting the machine down. This way you could return to a login dialog easily.<br />
* Finish the font dialog ( use ft2lib ? )<br />
* Finish the file dialog, or better fix it, and implement it as discussed in: [[ideas#wps]]<br />
* Make XWP and WPSWizzard/CWMM/ADC aware of eacht other. Please point out which problems arise when these packages are installed in parallel so we have point for starting discussion ;-).<br />
* Extend Program object by <br />
** allow for env variables to be set<br />
*** in a page within the settings notebook<br />
*** in a file *.env with the name of the executable<br />
** use strict libpath<br />
* add a cron/schedule folder. Only when a shadow of a program object is dragged into it once or more often (nothing else than shadows allowed in this folder)<br />
** the settings notebook then contains a notebook page 'schedule' or alike, containing the time settings<br />
** the context menu contains an item to activate the schedule item or to disable it<br />
** the icon shows an added bitmap (just like shadow objects) to indicate an active or inactive schedule)<br />
* Add the possibility to save the application settings '''once'''. So you can do your setup like you want it, you logoff once and it will be saved but it won't save it each time you logoff.<br />
* Compile against GCC<br />
<br />
=== XWorkplace: Ideas ===<br />
<br />
As soon as the developers of XWP agree with any of these ideas the topic should be moved up to the plan section.<br />
<br />
* Review the trashcan. It was never usable for me. Constant WPS lockups (Cinc)<br />
* Wrap the XWP file dialog into an object so it's usable using RWS until it's integrated globally into the system.<br />
* Add a function to set the standard browser. This is a common problem for quite some people.<br />
* Set a ctrl+alt+backspace key to hard reset the wps. Hard Reset without any questions.(Like *nix)<br />
* In Gnome you can attach so-called "emblems" to icons, as a remind for something (see http://xtracker.netlabs.org/index.php?binary=137 and http://xtracker.netlabs.org/index.php?binary=138 for two samples). Maybe these "emblems" could be added to icons of DataFile objects with a mechanism similar the one used for the "Mark shadow icons" function? We could have a menu item to select the "emblem" to attach to the file.<br />
<br />
====XCenter====<br />
* XCenter Transparency: Allow Transparency Button and a transparency percentage field (%)<br />
* XCenter tasklist widget menu: rearrange menu items s othat the close/kill items are at the bottom better reachable)<br />
* XCenter tray object menu: add 'locate' item of shadow objects, in order to quickly find the folder of the original item<br />
* Allow xcenter to be also included as a bar on WPS desktop windows. The idea will be to have xCenter widgets on the desktop windows like the common Windows bars like MSN Search bar, or other. It will be nice to have the Weather widgets on all the OS/2-eCS desktop windows.</div>Ggambahttps://wiki.netlabs.org/index.php?title=XWorkplace&diff=1583XWorkplace2005-09-25T16:32:36Z<p>Ggamba: /* XCenter */</p>
<hr />
<div>=== XWorkplace: Future plan ===<br />
<br />
This page is intended to discuss future updates or additions to XWP.<br />
<br />
* Create a logoff feature, which basicly does everything shutdown does, but afterwards exits the [[WPS]], like with restart WPS, instead of shutting the machine down. This way you could return to a login dialog easily.<br />
* Finish the font dialog ( use ft2lib ? )<br />
* Finish the file dialog, or better fix it, and implement it as discussed in: [[ideas#wps]]<br />
* Make XWP and WPSWizzard/CWMM/ADC aware of eacht other. Please point out which problems arise when these packages are installed in parallel so we have point for starting discussion ;-).<br />
* Extend Program object by <br />
** allow for env variables to be set<br />
*** in a page within the settings notebook<br />
*** in a file *.env with the name of the executable<br />
** use strict libpath<br />
* add a cron/schedule folder. Only when a shadow of a program object is dragged into it once or more often (nothing else than shadows allowed in this folder)<br />
** the settings notebook then contains a notebook page 'schedule' or alike, containing the time settings<br />
** the context menu contains an item to activate the schedule item or to disable it<br />
** the icon shows an added bitmap (just like shadow objects) to indicate an active or inactive schedule)<br />
* Add the possibility to save the application settings '''once'''. So you can do your setup like you want it, you logoff once and it will be saved but it won't save it each time you logoff.<br />
* Compile against GCC<br />
<br />
=== XWorkplace: Ideas ===<br />
<br />
As soon as the developers of XWP agree with any of these ideas the topic should be moved up to the plan section.<br />
<br />
* Review the trashcan. It was never usable for me. Constant WPS lockups (Cinc)<br />
* Wrap the XWP file dialog into an object so it's usable using RWS until it's integrated globally into the system.<br />
* Add a function to set the standard browser. This is a common problem for quite some people.<br />
* Set a ctrl+alt+backspace key to hard reset the wps. Hard Reset without any questions.(Like *nix)<br />
<br />
====XCenter====<br />
* XCenter Transparency: Allow Transparency Button and a transparency percentage field (%)<br />
* XCenter tasklist widget menu: rearrange menu items s othat the close/kill items are at the bottom better reachable)<br />
* XCenter tray object menu: add 'locate' item of shadow objects, in order to quickly find the folder of the original item<br />
* Allow xcenter to be also included as a bar on WPS desktop windows. The idea will be to have xCenter widgets on the desktop windows like the common Windows bars like MSN Search bar, or other. It will be nice to have the Weather widgets on all the OS/2-eCS desktop windows.</div>Ggambahttps://wiki.netlabs.org/index.php?title=XWorkplace&diff=1582XWorkplace2005-09-25T16:32:12Z<p>Ggamba: /* XCenter */</p>
<hr />
<div>=== XWorkplace: Future plan ===<br />
<br />
This page is intended to discuss future updates or additions to XWP.<br />
<br />
* Create a logoff feature, which basicly does everything shutdown does, but afterwards exits the [[WPS]], like with restart WPS, instead of shutting the machine down. This way you could return to a login dialog easily.<br />
* Finish the font dialog ( use ft2lib ? )<br />
* Finish the file dialog, or better fix it, and implement it as discussed in: [[ideas#wps]]<br />
* Make XWP and WPSWizzard/CWMM/ADC aware of eacht other. Please point out which problems arise when these packages are installed in parallel so we have point for starting discussion ;-).<br />
* Extend Program object by <br />
** allow for env variables to be set<br />
*** in a page within the settings notebook<br />
*** in a file *.env with the name of the executable<br />
** use strict libpath<br />
* add a cron/schedule folder. Only when a shadow of a program object is dragged into it once or more often (nothing else than shadows allowed in this folder)<br />
** the settings notebook then contains a notebook page 'schedule' or alike, containing the time settings<br />
** the context menu contains an item to activate the schedule item or to disable it<br />
** the icon shows an added bitmap (just like shadow objects) to indicate an active or inactive schedule)<br />
* Add the possibility to save the application settings '''once'''. So you can do your setup like you want it, you logoff once and it will be saved but it won't save it each time you logoff.<br />
* Compile against GCC<br />
<br />
=== XWorkplace: Ideas ===<br />
<br />
As soon as the developers of XWP agree with any of these ideas the topic should be moved up to the plan section.<br />
<br />
* Review the trashcan. It was never usable for me. Constant WPS lockups (Cinc)<br />
* Wrap the XWP file dialog into an object so it's usable using RWS until it's integrated globally into the system.<br />
* Add a function to set the standard browser. This is a common problem for quite some people.<br />
* Set a ctrl+alt+backspace key to hard reset the wps. Hard Reset without any questions.(Like *nix)<br />
<br />
====XCenter====<br />
* XCenter Transparency: Allow Transparency Button and a transparency percentage field (%)<br />
* XCenter tasklist widget menu: rearrange menu items s othat the close/kill items are at the bottom better reachable)<br />
* XCenter tray object menu: add 'locate' item of shadow objects, in order to quickly find the folder of the original item<br />
* Allow xcenter to be also included as a bar on WPS desktop windows. The idea will be to have xCenter widgets on the desktop windows like the common Windows bars like MSN Search bar, or other. It will be nice to have the Weather widgets on all the OS/2-eCS desktop windows.<br />
* In Gnome you can attach so-called "emblems" to icons, as a remind for something (see http://xtracker.netlabs.org/index.php?binary=137 and http://xtracker.netlabs.org/index.php?binary=138 for two samples). Maybe these "emblems" could be added to icons of DataFile objects with a mechanism similar the one used for the "Mark shadow icons" function? We could have a menu item to select the "emblem" to attach to the file.</div>Ggamba