Page MenuHomePhabricator

[lldb] move package generation from python to cmake
ClosedPublic

Authored by hhb on Oct 15 2019, 10:25 PM.

Details

Summary

This is the last part. And we can remove the python script.

Diff Detail

Event Timeline

hhb created this revision.Oct 15 2019, 10:25 PM
hhb planned changes to this revision.Oct 15 2019, 10:25 PM
hhb added a reviewer: labath.Oct 16 2019, 11:03 AM
Harbormaster completed remote builds in B39662: Diff 225268.

I'm sorry, this dropped off my radar. The only question I have here is about the createPythonInit.py script. If we're moving stuff to cmake, I am wondering if we shouldn't move that thing too? It doesn't look like the code is doing anything which would be hard to replicate in cmake. WDYT ?

hhb added a comment.Oct 25 2019, 4:05 PM

I'm sorry, this dropped off my radar. The only question I have here is about the createPythonInit.py script. If we're moving stuff to cmake, I am wondering if we shouldn't move that thing too? It doesn't look like the code is doing anything which would be hard to replicate in cmake. WDYT ?

I didn't find a good way to generate file using cmake at build time... Did I miss something?

The closest way I see is to create a new .cmake script with file(WRITE ...) in it. And invoke cmake to run this new script at build time. But that doesn't seem much better than this simple python script.

In my opinion, python is better than cmake for string processing. As long as we don't reinvent too many cmake functionality in python, it is not a problem to have a small python script...

Right. I see what you mean.

But... does this have to happen at build time? Since the list of files is already known at configuration time, you should be able to generate the files in the "cmake" step (but still leave the copying for the build step, so that any changes to the files are reflected in rebuilds).

(I'm not insisting on that -- I think that the current patch is already much better than what we had before. If you think that the python script is better than that, feel free to say so.)

hhb added a comment.Oct 27 2019, 4:41 PM

Right. I see what you mean.

But... does this have to happen at build time? Since the list of files is already known at configuration time, you should be able to generate the files in the "cmake" step (but still leave the copying for the build step, so that any changes to the files are reflected in rebuilds).

(I'm not insisting on that -- I think that the current patch is already much better than what we had before. If you think that the python script is better than that, feel free to say so.)

That could be done... Except that the path of these files can be determined at build time, at least for multi-configuration generators. So we may need to write them to a temporary path at configuration time, and copy them to the right Debug / Release directory at build time.

Yea let's use python for now... ๐Ÿ˜Š

labath accepted this revision.Oct 28 2019, 7:32 AM

Ok. sounds good.

This revision is now accepted and ready to land.Oct 28 2019, 7:32 AM
hhb updated this revision to Diff 226781.Oct 28 2019, 4:51 PM

Rebase

This revision was automatically updated to reflect the committed changes.