I am going to build a Python.exe to migrate it to another PC, in order to build a seemingly virtual *environment* of Python which could run python files. What I do to implement this is to *COPY* \win32 folder to another pc then execute python.exe with specific python file path tagged along.

For now, it works well, however, I met with a strange problem that I cannot find *tcl* under current file hierarchy and this library is generated very deeply so I have to extract it to the root directory manually. 

Surprisingly, I found that I can directly *COPY* all the folders generated by *msi installer* to another pc then use it. Nevertheless, I fret about there could be some registration thing during installation.

So how could I compile the source and make it generate folder hierarchy like the release version(like the snapshot I attached below)? I have read README.md in the \PCBuild yet it helps little.

Sorry I posted a wrong pic.

Have a look in the Tools/msi directory. The "build.bat" and "buildrelease.bat" files will generate the installers and other packages (note that you may need .NET 3.5 enabled on your machine).

You may also be able to use the make_zip.py script to help create a "full" distribution in a specific directory. Though it may still exclude Tcl and Tk (deliberately). It's not meant for replacing the full installer.

Sorry for not illustrating this clearly. What I need to build is a copyable, relocatable bunch of files which contains a directory like \bin then has an executable in it, so I can run Python directly. Notwithstanding I do not need a installer because I am not supposed to alter user's configuration. Thanks for your patience in advance!

Or say what the difference of the python executable generated from msi installer and built from source?

In that case, you are asking for a new feature development that we have previously decided is not in the best interests for us to provide (in that it leads to more upgrade and installation issues than a more controlled installer). If you are prepared to write and contribute scripts that do this, we can consider them against this bpo item, but if not then I suggest we close this as rejected.

In either case, we would not be offering this package on python.org.

---

There is no difference between the Python binaries. The difference is that the installer ensures they are properly integrated with Windows in a way that makes them easier to use, safer to update, and protects against conflicts between multiple copies. Apart from these, they can simply be copied around.

If the context for your question is that you know that you can't do this on other platforms, then my answer is that Windows always searches for dynamic libraries when loading them, rather than embedding an absolute path during build. So you can *only* create relocatable binaries, provided you also include all the dependencies (and it is not always obvious what these are).

Does that help?

Given that there has been no activity on this issue for over three years, I am closing this as "rejected".