search

trentforkert / cmake

Experimental CMake with D support
Other
16 stars 2 forks source link

Why don't you try to get your changes to upstream? #25

Open wilzbach opened 8 years ago

wilzbach commented 8 years ago

I think your project is great - have you ever thought about trying to submit your changes to upstream? I would assume that the devs are happy if cmake get's more generic and used.

trentforkert commented 8 years ago

Long ago, that was the plan. However,

  1. I got burned out pretty bad on this project a while back when I lost a load of work, including tests, a re-written parser, and a handful of bug fixes. I still haven't felt like returning to it.
  2. I won't even consider merging upstream until D gets proper shared library support on Linux, OS X, and Windows. I fully expect more bugs to show up once I can actually test those configurations. Shared library support has been on the horizon for a long time now.
  3. I've been moving away from D recently. C++ is annoying, but I was running into way too many bugs in D. Not to mention the fact that the D front end is a RAM hog. I want to like D. I've spent a lot of time with it, and prefer it to C++. I just don't really have the patience for it anymore.

IIRC, premake 5 (alpha) has built-in D support, so I'd recommend that if you're just looking for a better build system for your D code.

KingDuckZ commented 6 years ago

Hi, now that gdc is being officially merged into gcc, is there any hope to see any new development on this project? I'm starting a new project and I'm evaluating what language I should use - D would be pretty good for what I need but without decent cmake support that's going to be a dead end for me.

KingDuckZ commented 6 years ago

Any word at all?

mathstuf commented 5 years ago

I think Trent is done with D (this is his only project I can see on his GitHub profile and no activity at all for a long time). There may be hope of getting it into CMake itself, but it will need a champion. The first thing would be to work on getting this rebased on newer and newer CMake versions. I recommend rebasing on 3.1, testing it out, then rebasing on 3.2, testing again, and so on. Trying to go directly to 3.15 is going to just be overwhelming.

KingDuckZ commented 5 years ago

I don't know if I mentioned this already but I did try just that. I remember it was relatively easy up to a point when I think cmake did a full code restyling. From there on pretty much every single line conflicts. My work is here https://github.com/KingDuckZ/cmake but I recently discovered Meson and I've been using that for my D projects. In fact I like it so much that I've start using it even for my C++ projects.

mathstuf commented 5 years ago

Yeah, the reformat is going to be a pain for the rebase, but there are techniques for doing it (though you probably do need access to the reformatter tool). Between that and other codebase-wide sweeps like APIs taking strings rather than const char* and such, yes, it's a pain.

KingDuckZ commented 5 years ago

Yes, I pushed whatever work I was able to complete to github in case anyone wants to pick it up from where I left, but having discovered Meson I'm simply not motivated anymore. If you can, I suggest you give it a chance, I find its syntax to be much cleaner than cmake and it just works with D out of the box.

mathstuf commented 5 years ago

I'm aware of Meson. I'm also aware of its deficiencies and where it doesn't work for my CMake-based projects that I do work on (mainly related to it lacking full Fortran support and assuming that pkg-config is sufficient for every dependency out there). I also don't do much D at all these days (having instead figured that porting to Rust is easier than getting D to run well on Android). Alas, both those specific projects have fallen afoul of the "lack of time" problem :/ .