lewissbaker / cake Goto Github PK

Sometimes you will have a build script that builds an entire library potentially consisting of many source files. In addition it might also be a shared library (DLL) that requires linking with other libraries built in other build scripts. In the case of a top-level program build script it might end up building every source file.

Currently if you ask Cake to build a build script it builds everything in that build script and recursively builds everything required to build those things.

What would be nice is having a way to specify that you only want to build a certain target within a build script rather than having it implicitly build everything in that script. eg. only build an individual source file within a library or build all object files but skip any link step that might require building other libraries.

Imagine extending the command-line to allow specifying an optional list of target names after each build script. eg.

$ cake src/build.cake:foo.obj    # Just build foo.obj
$ cake src/build.cake:foo.obj,bar.obj,baz.obj    # Build multiple named targets

Build scripts (or tools called by build scripts) could register named targets with the current root script using an API that looks something like the following:

from cake.tools import script, sometool

# Tool may automatically register the returned target under the name 'sometarget'.
someTarget = sometool.build(target='sometarget')

# Script could manually register the target under a different name
script.addTarget('anothername', someTarget)

Build scripts could refer to named targets from other build scripts to indicate some dependency or to republish the other build script's targets under a name in the current build script.

from cake.tools import script

otherScript = script.get(script.cwd('other.cake')

# Get a reference to a named target from another script.
# Note this would not cause other.cake to be executed unless the returned target
# was used by something.
otherObjects = otherScript.getTarget('objects')

# Could republish the other script's named targets as our own so that when
# this script is asked to build 'objects' it would result in building 'objects'
# target from other.cake.
script.addTarget('objects', otherObjects)

In terms of implementation, we'd need to introduce the concept of a lazy task or lazy target so that a script can execute, define how to build a bunch of targets but not actually build any of them unless those targets have been requested to be built.

If the user just asks for a build script to be built without specifying a named target (as is currently supported) then the behaviour should be as per the current behaviour. ie. build all targets defined in that build script.

We currently require Python 2.7 to run but this is now quite old.

We could take advantage of new Python libraries and features if we port to Python 3.6. Eg async functions.

I'm not sure if we need to support older versions of Python 3.x but as there aren't many users yet it's probably not a high priority.

Update the cake.library.compilers.msvc.findMsvcCompiler() function to support searching for Visual Studio 2015 compiler.

Currently (2015-01-18) the final release is not yet available. However there is a 2015 CTP version currently available that could be used for developing support assuming the final release won't change too much.

The Cake build system up until now has relied on the registry to determine whether a particular Visual Studio version is installed and if so where it is installed.

With Visual Studio 2017 this has changed: https://blogs.msdn.microsoft.com/heaths/2016/09/15/changes-to-visual-studio-15-setup/

We need to add a new function to cake.library.compilers.msvc to find the installation path of VS 2017 using the new COM API.

When using the object-file cache we could use file-system linking to avoid copying unnecessarily, either when adding files to the cache or retrieving files from the cache. This can help to reduce build times and also reduce disk space usage.

Where hard-linking is supported and the cache directory is on the same volume as the built object-file we could hard-link the cached file to the same file as the built object-file. This would eliminate a copy operation when inserting objects into the cache and when the built object-file is removed the cache copy would still remain available.

Where symbolic-linking is supported and we want to use an object file from the cache, we could create a symbolic link to the object file in the cache directory rather than copying the file from the cache directory into its final destination.

Both of these linking approaches would come with the caveat that the build should not modify the object files after they have been built. We could possibly enforce this if linking was enabled by setting the file permissions to read-only.

The resulting error message is:

  File "D:\VCS\cake\src\cake\library\compilers\gcc.py", line 506, in _getCommonLinkArgs
    if dll and self.importLibrary is not None:
AttributeError: 'WindowsMinGWCompiler' object has no attribute 'importLibrary'

Based on MacGccCompiler, the WindowsMinGWCompiler should be extending _getLinkCommands() such that the importLibrary parameter is available rather than trying to access it from self.

If it was self.importLibrary , it seems kind of strange as that would seemily imply the Compiler only has one such import library path.

On Windows when you run through an edit/compile/debug cycle often it can be quite annoying having build failures due to the linker not being able to write to the .dll or .exe target because they are currently in use by a running process (typically the process you were just using to test/debug).

It save some developer frustration and time if cake could be configured to automatically find all processes that currently have a .dll/.exe loaded and kill those processes before running the linker.

Now that we have lazy-tasks and named targets we can remove the need for 'enabled' property on tools which was used for switching between different build modes.

For example, specifying -p flag would enable a 'project building' mode which would disable all tools except for the project tool so that you could build .vcproj files without compiling the code.

We should now be able to do this with named targets and lazy tasks/builds instead of disabling certain tools.
eg. have the project tool define an @projects target to allow you to build .vcproj files

Add support for building C/C++ code using the clang compiler.

cake.library.project imports cake.library.compilers.msvc simply for the type MsvcCompiler so it can determine if the compiler used is MSVC or not.

By doing this it fails because that imports cake.msvs which then tries to import _winreg (Linux doesn't provide the Windows registry).

Fundamentally there should be no reason why project files for shouldn't be buildable on Windows. While I am unaware of any other tools that would find a use for vcproj file, it would be a pain having to conditionally the use of the project tool in cake scripts based on platform.

Traceback (most recent call last):
  File "/root/.local/lib/python2.7/site-packages/cake/runner.py", line 454, in run
    configuration = engine.findConfiguration(scriptPath)
  File "/root/.local/lib/python2.7/site-packages/cake/engine.py", line 335, in findConfiguration
    return self.getConfiguration(configScript)
  File "/root/.local/lib/python2.7/site-packages/cake/engine.py", line 308, in getConfiguration
    script.execute()
  File "/root/.local/lib/python2.7/site-packages/cake/script.py", line 273, in execute
    exec byteCode in scriptGlobals
  File "/root/descentreader/config.cake", line 19, in <module>
    from cake.library.project import ProjectTool
  File "/root/.local/lib/python2.7/site-packages/cake/library/project.py", line 26, in <module>
    from cake.library.compilers.msvc import MsvcCompiler
  File "/root/.local/lib/python2.7/site-packages/cake/library/compilers/msvc.py", line 19, in <module>
    from cake.msvs import getMsvcProductDir, getMsvsInstallDir, getPlatformSdkVersions, getWindowsKitsDir, vswhere
  File "/root/.local/lib/python2.7/site-packages/cake/msvs.py", line 10, in <module>
    import _winreg as winreg
ImportError: No module named _winreg
Build failed with 1 errors.

Should just require a new ProjectTool.VS2015 constant that maps to appropriate MSBuild file version and .sln file version.

just like this below:
gcc -DUSE_** test.cpp -o test
I want to define macro maybe like this: cake --macro=USE_,USE

I check cake source, and found the options supported only this:
`Usage: run.py [options] *

Options:
-h, --help Show this help message and exit.
-v, --version Print the current version of Cake and exit.
--args=FILE Path to the args.cake file to use.
--config=FILE Path to the config.cake configuration file to use.
--debug=KEYWORDS Set features to debug, eg:
'reason,run,script,scan,time'.
-s, --silent, --quiet
Suppress printing of all Cake messages, warnings and
errors.
-f, --force Force rebuild of every target.
-jJOBCOUNT, --jobs=JOBCOUNT
Number of simultaneous jobs to execute.
-k, --keep-going Keep building even in the presence of errors.
-eCOUNT, --max-errors=COUNT
Halt the build after a certain number of errors.
-l, --list-targets List named targets in specified build scripts.
-p, --projects Create projects instead of building a variant.
--clang-install-prefix=PATH
Path where clang has been installed.
--clang-executable=FILE
Name or full-path of clang executable to compile with
--libcxx-install-prefix=PATH
Path where libc++ has been installed. Defaults to
value of --clang-install-prefix
--gcc-executable=FILE
Name or full-path of g++ executable to compile with`

Like #7, this should just require a new ProjectTool.VS2017 constant that maps to appropriate MSBuild file version and .sln file version.

The following is from a freshly created Visual C++ Win32 project solution file (.sln)

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.26228.10
MinimumVisualStudioVersion = 10.0.40219.1

And from the vcxproj file the <Project ToolsVersion="15.0"> while the PlatformToolset is v141 while there is a of 15.0

Use Markdown so that it's rendered nicely on github.

Add some examples of build scripts.
Update info on supported compilers
Add some benchmarks

Possible topics

• configurations and variants
• structuring large c/c++ code bases
• writing your own tools
• script execution and inclusion
• extending commandline args to cake
• generating visual studio projects