I have a WIP CMake migration patch with the main QBE binary,
installation, and test targets migrated to CMake with a few remaining
ones that may be migrated into the tools directory (config.h,
80-column limit check, source listing, `wc`), but I'm not sure if it
will be useful for this project (and have seen one opinion against
moving to CMake) so I'd like to survey first before I finish the patch
and send a merge request.
The biggest benefits would be editor integrations with VS, VSCode, and
other IDEs that support CMake. With it, editors can provide smarter
autocompletions, browse tests, quick ways to debug, etc. etc., you get
the idea. CMake also allows putting binaries in a separate build
directory. Would that be useful to have in the project?
I have also attached the (WIP) patch in case anyone wants to give it a try.
The patch is not appearing on the online archive despite being
attached to the email. I hope I didn't make a dumb mistake?
On Sun, Dec 29, 2024 at 12:31 PM Atirut Wattanamongkol
<atirut.wattanamongkol@gmail.com> wrote:
>> I have a WIP CMake migration patch with the main QBE binary,> installation, and test targets migrated to CMake with a few remaining> ones that may be migrated into the tools directory (config.h,> 80-column limit check, source listing, `wc`), but I'm not sure if it> will be useful for this project (and have seen one opinion against> moving to CMake) so I'd like to survey first before I finish the patch> and send a merge request.>> The biggest benefits would be editor integrations with VS, VSCode, and> other IDEs that support CMake. With it, editors can provide smarter> autocompletions, browse tests, quick ways to debug, etc. etc., you get> the idea. CMake also allows putting binaries in a separate build> directory. Would that be useful to have in the project?>> I have also attached the (WIP) patch in case anyone wants to give it a try.
On Sun, Dec 29, 2024 at 10:52 AM Drew DeVault <sir@cmpwn.com> wrote:
> Absolutely not. For the love of god please do not apply this patch, mpu.
+1 vote.
CMake is incredibly bloated, complex, unintuitive, and poorly
documented; is an awful dependency to have in your bootstrapping
process; and I will not touch it with a thirty foot pole. I used to use
it before I knew better and these days I very much know better.
For qbe simple Makefiles are sufficient. For (much!) more complex
programs, muon+samurai is better than CMake.
I completely agree with Drew and Jan. CMake is bloated, impossible to
bootstrap, and... yeah, no.
What you could instead do is to use https://github.com/rizsotto/Bear,
which would create compile_commands.json that clang tooling (e.g.
clangd, ccls, and probably many more language servers) recognize.
I'm not sure how test integrations work, and I'm not convinced they'll
really be useful for qbe.
Bear is available in many, many repositories:
https://repology.org/project/bear-clang/versions
--
Best regards,
Runxi Yu (they/them)
Year 11, E House
YK Pao School SJ
https://runxiyu.org
> What you could instead do is to use https://github.com/rizsotto/Bear,> which would create compile_commands.json that clang tooling (e.g.> clangd, ccls, and probably many more language servers) recognize.> Bear is available in many, many repositories:> https://repology.org/project/bear-clang/versions
Nice! This will be a great addition to my existing Makefile projects.
Would it be a better idea to integrate that with QBE? Editor
integrations could make development way more convenient.
On Sun, Dec 29, 2024, at 12:12, Atirut Wattanamongkol wrote:
> Nevermind, `bear -- make` literally just works. Sorry for the noise.
No problem, looking forward to your other contributions :).
Quoth Atirut Wattanamongkol <atirut.wattanamongkol@gmail.com>:
> > Absolutely not> > Hm? Why not, if you don't mind? I've been using CMake in all of my> C/C++ projects for the editor integrations, so I'm curious.>
The last time I tried to do something non-trivial with cmake
I found myself debugging cmake with gdb to figure out what
script was screwing up the environment.
it's giant and undebuggable. It's incredible to me that the
C++ world didn't look at it and ask "are you pranking me?"
do you know how you return variables from a cmake function?
you find the environment of the calling function, and modify
its local variables to include a new name. Here's an example:
FUNCTION(MY_FUNC_WITH_RET retname, val)
SET(${ret} 2*val PARENT_SCOPE)
ENDFUNCTION()
MY_FUNC_WITH_RET(returned_value, 42)
Just to show that you're not imagining things, and it is as
insane as it sounds, the equivalent python is below:
def do_return(varname, val):
f = inspect.currentframe()
f.f_back.f_locals[varname] = 2*val
do_return("returned_value", 42)
print(returned_value) # prints 84
the build system isn't any better than the language.
On Sun, Dec 29, 2024 at 11:16:27AM +0100, Jan Mercl wrote:
> On Sun, Dec 29, 2024 at 10:52 AM Drew DeVault <sir@cmpwn.com> wrote:> > > Absolutely not. For the love of god please do not apply this patch, mpu.> > +1 vote.
+2 vote.