[Tarantool-patches] [PATCH v3 1/9] build: add Christian Hansen c-dt to the build
Vladislav Shpilevoy
v.shpilevoy at tarantool.org
Sun Aug 8 17:34:43 MSK 2021
On 05.08.2021 11:55, Safin Timur wrote:
> Hello Vlad!
>
> On 05.08.2021 2:58, Vladislav Shpilevoy wrote:
>> Hi! Thanks for the patch!
>>
>> On 02.08.2021 02:40, Timur Safin via Tarantool-patches wrote:
>>> * Integrated chansen/c-dt parser as 3rd party module to the
>>> Tarantool cmake build process.
>>> * Points to tsafin/c-dt instead iof original chansen/c-dt to
>>> have easier build integration, because there is additional
>>> commit which integrated cmake support
>>
>> As I said in the previous review, it points at
>> https://github.com/tarantool/c-dt.git, not at tsafin/c-dt. Why
>> do you keep saying the contrary? Look:
>>
>> url = https://github.com/tarantool/c-dt.git
>>
>> It is 'tarantool', not 'tsafin' here.
>
> Yes, that was oversight, due to several restarts of rebase session
> (I guess due to mess generated with combination of --autosquash and git rerere)
> Now finally applied to this commit in branch as commit #4b90de3bb21b9f28bc7c1f8e851d4c95f1b0f191.
>
>>
>> Also, like on the previous review, when I call 'make' and do
>> 'git status', I see:
>>
>> Changes not staged for commit:
>> (use "git add <file>..." to update what will be committed)
>> (use "git restore <file>..." to discard changes in working directory)
>> (commit or discard the untracked or modified content in submodules)
>> modified: third_party/c-dt (modified content, untracked content)
>>
>> You still didn't fix it. Please, do.
>>
>
> That was not a problem for me, due to the fact I _always_ use out-of-source build, and all artifacts generated separately under ${CMAKE_CURRENT_BINARY_DIR}/third_party/c-dt/, and such artifacts
> inside of source tree problem observed only when you do (not very idiomatic) in-source build. cmake generated Makefile overwrite original c-dt Makefile.
>
> [While we are here, could you please remind me why we recommend to use in-source build in our documentation?
> And not prefer the recommended and used by majority of industry for what matter out-of-source build?]
No idea. I personally use in-source build because I have just used to it.
> We could rather may not influence how and where artifacts will be generated from inside of our own c-dt/CMakeLists.txt, we should rather modify the way how it get used, like, not include it via simple add_subdirectory(which is exactly defining this ${CMAKE_CURRENT_BINARY_DIR}/third_party/c-dt, which would be equal to ${CMAKE_CURRENT_SOURCE_DIR}/third_party/c-dt for in-source build, but rather use some ExternalProject_Add() techniques, which allows to redefine generated and binary files localtion. Let me check what is the easiest way here...
I am not a cmake master, so I don't know a correct way to fix it. But I
don't understand why do you need Makefile in c-dt at all if it works via
cmake anyway and 100% of that Makefile is simply overwritten. It is not
used. If a file is not used and is overwritten anyway, why not drop it
from the repository?
Also I see
Untracked files:
(use "git add <file>..." to include in what will be committed)
libcdt.a
You need to update gitignore so as there is no the warning.
More information about the Tarantool-patches
mailing list