This is the readme for the emerge scripts to build kde on windows.

contents:
1. step-by-step guide
2. emerge options
3. the environment and the directory layout
4. remarks to the step-by-step guide
5. Authors, Contact and License

1. step-by-step guide
    - Get Python >= 2.5 ( e.g. from http://www.python.org ).
    - If you can read this file you probably already got the svn-sources.
      If not, get an svn client, preferrably TortoiseSVN ( from 
      http://tortoisesvn.net/downloads ).
    - If you have not done already: make up a directory kderoot somewhere;
      We will refer to it as %KDEROOT% or just kderoot - the name is not
      important at all though.
    - Put another directory emerge into %KDEROOT% enter that directory
      and checkout from svn://anonsvn.kde.org/home/trunk/kdesupport/emerge .
    - Add another directory etc to %KDEROOT%. Copy the file 
      kdesettings-example.bat from the emerge directory into the etc 
      directory. Rename kdesettings-example.bat to kdesettings.bat and edit it
      according to your needs.
    - open up kdeenv.bat from the emerge directory, try 'emerge -p kdebase'
      and if there are no errors, you can use emerge.

2. emerge options
Since there is no real help available for emerge, I will try to lay out all 
options here. Some options should be used with extreme caution since they will
make your kde installation unusable in 999 out of 1000 cases.

emerge is a tool for building KDE-related software under Windows. emerge
automates it, looks for the dependencies and fetches them automatically.

The basic Syntax of an emerge call is that one:

emerge [[ options ][ flags ][ firstPackage ] 
        [ options ][ flags ][ secondPackage ] ...]

options:
--print-installed               This will show a list of all packages that
                                are installed currently. It queries both
                                databases (etc\portage\installed) and the
                                manifest directory - it prints out only those
                                packages that are contained within
                                --print-installables
--print-installables            This will give you a list of packages that can
                                be installed. Currently you don't need to
                                enter the category and package: only the
                                package will be enough.
--print-targets                 This will print all the different targets
                                one package can contain: different releases
                                might have different tags that are build as
                                targets of a package. As an example:
                                You could build the latest amarok sources
                                with the target 'svnHEAD' the previous '1.80'
                                release would be contained as target '1.80'.
--buildtype=[BUILDTYPE]         This will override the build type set by the
                                environment option EMERGE_BUILDTYPE .
                                Please set it to one out of Release, Debug,
                                RelWithDebInfo, MinSizeRel
--target=[TARGET]               This will override the build of the default
                                target. The default Target is marked with a
                                star in the printout of --print-targets

build steps:
--fetch             for most non-KDE packages: retrieve package sources.
--unpack            for most non-KDE packages: unpack package sources and make
                    up the build directory.
                    for KDE packages: get package source from SVN and make up
                    the build directory.
--compile           compile the sources: this includes configure'ing/cmake'ing
                    and running [mingw32-|n|]make.
--install           This will run [mingw32-|n|]make install into the image 
                    directory of each package.
--manifest          This step creates the files contained in the manifest dir.
--qmerge            This will merge the image directory into the KDEROOT
--package           This step will create a package out of the image directory
                    instead of merge'ing the image directory into the KDEROOT
--full-package      This will create packages instead of installing stuff to
                    KDEROOT
--unmerge           this uninstalls a package from KDEROOT - it requires a
                    working manifest directory.

flags:
-i          ignore install: using this option will install a package over an
            existing install. This can be useful if you want to check some
            new code and your last build isn't that old. This option might
            cause some problems though: if you want to update Qt e.g. the
            building of qmake depends on the existance on the system - thus
            using -i will result in a wrong qt package (as has happened when
            updating from qt4.3 to qt4.4).
-p          probing: emerge will only look which files it has to build
            according to the list of installed files and according to the
            dependencies of the package.
-q          quiet: there should be no output - The verbose level should be 0
-t          test: if used on an KDE target it will override the environment
            variable and build the target with -DKDE_BUILD_TESTS=ON
-v          verbose: increases the verbose level of emerge.
            verbose level 1 contains some notes from emerge, all output of
            cmake, make and other programs that are used. verbose level 2
            adds an option VERBOSE=1 to make and emerge is more verbose
            highest level is verbose level 3.
--noclean   this option will try to use an existing build directory. Please
            handle this option with care - it will possibly break if the
            directory isn't existing.
--nocopy    this option is deprecated. In older releases emerge would have
            copied everything from the SVN source tree to a source directory
            under %KDEROOT%\tmp - currently nocopy is applied by default if
            EMERGE_NOCOPY is not set to "False". Be aware that setting
            EMERGE_NOCOPY to "True" might slow down the build process,
            irritate you and increase the disk space roughly by the size of
            SVN source tree.
--offline   do not try to connect to the internet: KDE packages will try to
            use an existing source tree and other packages would try to use
            existing packages in the download directory. If that doesn't
            work, the build will fail.
--update    this option is the same as '-i --noclean'. It will update a single
            package (that is already installed. SE: I will change this sooner
            or later)
            
Internal options or options that aren't implemented yet:
PLEASE DO NOT USE!
--version-dir
--version-package

3. the environment and the directory layout
For running emerge in a preset environment, please use the kdeenv.bat. this
will set all Environment variables for you that are needed to build KDE4.
Please be aware that cygwin shouldn't be in your path.
KDE on windows uses a special layout that might change in future releases.
Below %KDEROOT% you will find common unix folders such as bin, lib and etc.
There are some special folders that have another meaning though:
\emerge     This folder contains the portage directory, the emerge scripts
            within the folder bin, this README and the kdesettings-example.bat
\tmp        This folder contains the build directories of all packages.
            After finishing with emerge, you can empty this folder.
\etc        this folder contains lots of settings.
\bin        Contains all executables and all shared libraries.
\lib        Contains all non-shared libraries.
\include    Contains header files.
\share      Contains lots of additional stuff: Wallpapers,mimetype definitions
            and some more.
\mingw      This folder only exists if you install mingw or gdb with emerge.
            The kdeenv.bat will include this folder into the path for you.
            You can of course use this compiler outside of KDE as well.

4. remarks to the step-by-step guide
    - Get Python >= 2.5 ( e.g. from http://www.python.org ).

Python should be within your path ( which is normally set automatically ).
You don't have to register python with the file ending .py though the author
of these lines finds it useful.


    - If you can read this file you probably already got the svn-sources.
      If not, get an svn client, preferrably TortoiseSVN ( from 
      http://tortoisesvn.net/downloads ).

TortoiseSVN is an extension to the Windows Explorer and a full featured svn
client. It makes development easy. The point in not using a commandline client
is that emerge will not check for an installed commandline client yet.


    - If you have not done already: make up a directory kderoot somewhere;
      We will refer to it as %KDEROOT% or just kderoot - the name is not
      important at all though.

As already stated the name isn't really important. Currently all KDE files
will be installed under KDEROOT, but this might change in the future. 


    - Put another directory emerge into %KDEROOT% enter that directory
      and checkout from svn://anonsvn.kde.org/home/trunk/kdesupport/emerge .
      
If you want to directly work on emerge itself, please checkout from the normal
svn server instead.

      
    - Add another directory etc to %KDEROOT%. Copy the file 
      kdesettings-example.bat from the emerge directory into the etc 
      directory. Rename kdesettings-example.bat to kdesettings.bat and edit it
      according to your needs.
      
The file kdesettings-example.bat should contain all necessary informations.
You should read at that point.


    - open up kdeenv.bat from the emerge directory, try 'emerge -p kdebase'
      and if there are no errors, you can use emerge.

You will get a list of packages that emerge would try to build.
You can most of the time ignore warning messages - they are mostly for your
information.

5. Authors, Contact and License
There were multiple authors working on these scripts:
Holger Schrder
Patrick Spendrin
Christian Ehrlicher
Jaroslaw Staniek
Shane King

You can contact us via our mailing list kde-windows@kde.org

License: the file portage_versions.py can be used
under GPLv2 all other files are licensed (if needed) under BSD