id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 115,Use $(target) instead of $(out) for target shortcuts,dmik,,"As a convenience, kBuild generates ""phony"" targets as shortcuts to all defined targets, using this expression: {{{ $(basename $(notdir $(out))):: $(out) }}} Given the following def: {{{ PROGRAMS += myapp myapp_TOOL = ... myapp_SOURCES = ... }}} this will allow you to issue `kmk myapp` (instead of `kmk /path/to/obj/mybin/myapp.exe`) in order to only build `myapp`. This works fine until there are no targets with the same name. Since kBuild uses the same namespace for all targets, you can't e.g. have both the `PROGRAMS` and `DLLS` targets named `myapp` (even though they produce different files, `myapp.exe` and `myapp.dll`). The only way to overcome this limitation is to use the `NAME` property: {{{ DLLS += myapp_dll myapp_dll_NAME = myapp ... PROGRAMS += myapp ... }}} This works fine until you want to use the target shortcuts. Since kBuild derives these shortcuts from the actual file name by stripping the path and the extension, they are affected by the `_NAME` property. So, in the above case there will be a single `myapp` shortcut referring both to `myapp.exe` and `myapp.dll` (making it impossible to build them separately, for instance). It seems more logical to use the definitive target name directly for such shortcuts (which would give us `myapp_dll` and `myapp` in the above example, respectively). This namealready acts as a reference to the target in kBuild (when defining its properties for example), so this is what I expected in the first place actually (before I found that $(out) is used). The user will always make sure that there are no two targets with the same kBuild name which ensures there will always be an unique shortcut for each target. The relative change in kBuild to get it like that is as easy as: {{{ $(target):: $(out) }}} ",defect,new,major,,kBuild,0.1.5,,,