-
Notifications
You must be signed in to change notification settings - Fork 21
Home
I've set up a sub-Reddit section for discussion purposes, since GitHub doesn't have really much in the way of discussion fora functionality. It may still be empty since it was just created.
CIDLib is easy to build. But it is a full featured system and so there's a good bit of prep work needed to get the environment set up.
The following need to be installed. As a rule, probably generally a good one, don't let any of these guys set actual Windows environment variables, other than to add themselves to the PATH at most. We want to control the environment ourself. I don't think any of them actually do try to set up anything other than the path these days.
- Windows 7 or above
- Visual Studio 2017. It's very unlikely it will work with 2019 (the environment setup stuff I mean) because they swizzle things around crazily every time. VS versions are easily installed side by side so it should not be an issue to install 2017 even if you are already using 2019.
- Windows Platform SDK 10
- The Microsoft Speech Platform SDK 11. This is still, AFAIK, not part of the platform SDK that gets installed with VS 2017. Hopefully it will become so in 2019 to get rid of another moving part.
- The Windows Media Format SDK (still not in the regular platform SDK, right?)
- The Windows Media Player SDK (still not in the regular platform SDK, right?)
- The Quick Time SDK (only really used in CQC so far, the iTunes COM interfaces are in the .\Depends\SDKs directory, this is the actual SDK/engine.)
- LibVLC. Here again, currently really only used in CQC so far, and the headers/libraries are in the .\Depends\SDKs directory, this is the actual VLC player and DLLs.
- Scintilla but everything needed is in the .\Depends\SDKs directory, so nothing to do here.
You will need to set up a few things in the environment. Or, if you don't want to do that, then below where we invoke the environment command file, put your own file first, set these up, then call the the actual one. It opens a command window which will inherit the variables you set in your initial file before you invoke the real one.
CID_DEVTREE - This is the top of the development tree. Because there may be others that are based on CIDLib and part of the same build environment, you should do some sort of setup like this:
- C:\Whatever\MyWork\CIDRepos
- C:\Whatever\MyWork\CIDRepos\CID_Dev
Point this variable at the CIDRepos directory, and put the CIDLib code into the CID_Dev directory. The environmental setup file will add the CIDLib subdirectory. Any other related repos will do the same for their own sub-directories.
The rest are to let the build environment setup files get the INCLUDE, LIB, and other paths set. These are listed below, with examples from my own system. They should be fairly self-explanatory. The two VER ones are the specific versions of the platform SDK and Visual Studio tools you have installed, since those versions are in the paths to the various bits and pieces.
- CID_PLATSDKVER=10.0.17763.0
- CID_QTSDK=C:\Program Files (x86)\QuickTime SDK
- CID_SPEECHPLATDIR=C:\Program Files (x86)\Microsoft SDKs\Speech\v11.0
- CID_VSTOOLSVER=14.16.27023
- CID_VSTUDIOPATH=C:\Program Files (x86)\Microsoft Visual Studio\2017
- CID_WMFSDKDIR=C:\Program Files (x86)\Microsoft SDKs\WMFSDK\WMFSDK9
- CID_WMPSDKDIR=C:\Program Files (x86)\Microsoft SDKs\WMPSDK\WMPSDK10
Once those are in place you should add a general command line shortcut to your desktop somewhere. It will invoke the setup file which will set up everything you need into a command line windows. You should set up the Target: value (the command line to invoke) to be something like:
%SystemRoot%\System32\Cmd.exe /k %CID_DEVTREE%\CID_Dev\Source\Cmd\Win32\SetCIDEnv.Cmd Dev WIN32_WIN7 D: \CQSL\Develop\DevRoot\5.x\CID_Dev
This will invoke Cmd.Exe to run a command window. /k will make it stay open after the command file is run. It uses CID_DEVTREE above to find and invoke the CIDLib environment setup file. It passes the following values:
- Build Mode - This will be Dev or Prod for develop or production builds.
- Target Platform - Currently the only one is Windows 7 in Win32 mode, which is WIN32_WIN7
- Target Drive - The drive (with colon) that the CIDLib code is on. It's sort of redundant but it's annoying to parse stuff out in the Windows batch language, so it's easier to just provide it than to try to get it out of a passed path
- CID_Dev directory path - This is the path (minus drive and colon) to your CID_Dev directory. In my system 5.x is the equivalent of CIDRepos above, and CID_Dev is where I have the CIDLib code.
That's it for the environmental setup. You can set up two of these guys, and give one the name CIDLib Debug and one CIDLib Production or whatever, and set the first parameter to Dev for one and Prod for the the other.
To run the environment setup, just right click and run as admin. It's possible everything will work without running as admin, but I think some of the tools might require it. If you are paranoid, just look through the SetCIDEnv.Cmd file that gets invoked. It's just environment setup stuff.
That will open a command line prompt. You should be able to do something like:
CCD Root
and it should go to your CID_Dev directory. If so, you are roughly correct. Of course try cl.exe and link.exe and devenv.exe and other obvious Visual C++ tools to make sure that they are in the path correctly.
Do "set CID" to see the various CIDLib environment variables it has set for you. And of course you can just do:
Set > env.txt
to dump the whole environment out and peruse through what it has set up in your text editor.
The first thing you need to do is build the build tool. This is part of the bootstrapping process. This one is built via a simple make file. So type "CCD cidbuild" which should take you to the CIDBuild directory. Then run this command:
Win32\Cmp
That should build the build tool. If that succeeds, then probably the basic Visual C++ environment is good. If there are errors, then post the error output for comment. You should be able to run:
CIDBuild
And get the usage output from the build tool if it got built correctly.
Once you have the build tool built, then you need to do a bootstrap build. There are some bootstrapping issues invoked when you are building from an empty output directory. Because CIDLib uses its IDL compiler in a lot of places, that has to get built first, then the IDL compiler gets invoked for the whole code tree to generate all of the IDL output files, then a full build needs to be done.
You can do that with this command:
cidbuild /bootstrap
You should see it building CIDKernel, CIDLib, CIDXML and a few others that the IDL compiler needs. Then it will invoke the IDL compiler, then it will start building everything else.
If that completes successfully, then you have a working CIDLib build. Again, if not, post the errors and we can explore what's wrong.
Everything is pushed to the CID_Dev\Output directories. Under there you should see a directory that is the current working version. Under there will be DevResult and ProdResult directories (at least for the Dev/Prod modes you have built for) that have all of the output.
For each facility (DLL/Exe) there will be a [name].Out directory where the .obj files and other bits go. The Exe/DLL files and related compiler housekeeping files are in the Dev/ProdResult directories. There will be Includes and PrivIncludes directories where the headers are copied. The debugger will see these headers.
The output directories are in the path so you can run any of the built programs of course. You should be able to type:
CIDIDL
and get the usage output from the IDL compiler.
The CIDBuild tool does header dependency analysis. All sytems headers use <> brackets and all CIDLib (and your) headers should use "" quotes. CIDBuild knows that the latter are ones it cares about. It will generate a [name].Depend file in the [name].Out directory for each facility.
If you change headers you need to update the dependency file. You can do that like this:
CIDBuild /action=makedeps
If you don't give a target project, it does them all. If you want to do a specific facility project do:
CIDBuild /action=makedeps /Target=CIDLib
or whatever the target project is. If you know you don't need to recurse into other projects it depends on, use the /NR flag:
CIDBuild /action=makedeps /Target=CIDLib /NR
If you don't give an action then a build is assumed, so:
CIDBuild /Target=CIDIDL
will build the CIDDL project and any underlying projects. If you know you don't need to recurse (only change changed stuff at this level) you can use /NR.
CIDBuild /Target=CIDIDL /NR
If none of the underlying stuff had changed, then they wouldn't actually rebuild anyway, but you avoid the need for the compiler to have to figure that out himself.
I'll leave it there for this document. This is enough to sort of bootstrap the process. The rest of the docs will be in the actual repo and built to HTML using a tool you'll build above (that is not done yet, just saying that is how it will work.) So I want to keep this part as basic as is reasonable.