[CMake] Makefile doesn't automatically create executable path as Ninja

[Andreas Pakulat]

Hi,

On Tue, Sep 3, 2013 at 7:41 PM, Felipe Menezes Machado <felipou at gmail.com>wrote:

> On Tue, Sep 3, 2013 at 2:33 PM, Matthew Woehlke <
> matthew.woehlke at kitware.com> wrote:
>
>> On 2013-09-03 13:21, Felipe Menezes Machado wrote:
>>
>>> I'm having trouble understanding this behavior: what happens if the
>>> directory of the executable doesn't exist?
>>>
>>> I created a minimum example CMakeLists.txt (where foo.cpp is just a hello
>>> world):
>>>
>>> add_executable(test/test.bin foo.cpp)
>>>
>>> If the "test" directory doesn't exist, should the build system create it?
>>>
>>
>> Well, ninja seems to think so :-).
>>
>>
>>  Does that depend on the build system?
>>>
>>
>> Yes; ninja has a feature where it creates any non-existing directories
>> that are used by any outputs. At least make does not have a similar
>> feature. I don't know about other generators (e.g. xcode, msvc).
>>
>>
>>  I tested with make, it gives an error when executing "ld":
>>>
>>> /usr/bin/ld: cannot open output file test/test.bin: No such file or
>>> directory
>>>
>>> The command that generates the executable and gives the error is (from
>>> "make VERBOSE=1"):
>>>
>>> /usr/bin/c++       CMakeFiles/test/test.bin.dir/**foo.cpp.o  -o
>>> test/test.bin
>>> -rdynamic
>>>
>>> On the other hand, when I tested it with Ninja, it created the directory
>>> and finished without errors.
>>>
>>
>> Interesting question. I suppose CMake could be taught to generate make
>> rules to emulate ninja's behavior.
>>
>> Whether or not such a thing should be done is an interesting question.
>> (Especially as it probably should be done for all generators, it at all.)
>>
>>
>
> It would at least be a very interesting optional feature. Like something
> you specify in your CMakeLists.txt file, that every output directory should
> be created.
>

Well, IMO you're somewhat misusing cmake here, the add_executable and
add_library commands are intended to get the _names_ of targets. Not some
relative path to the dedicated output file. If you want to influence where
the binary goes you can do so with the corresponding target properties (see
RUNTIME_OUTPUT_DIRECTORY and OUTPUT_NAME).

So supporting relative paths as target name would pose a second way to
achieve the same thing which may be considered uneeded and possibly
confusing.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130903/c5672f9a/attachment-0001.htm>