search

atilaneves / reggae

Build system in D, Python, Ruby, Javascript or Lua
BSD 3-Clause "New" or "Revised" License
185 stars 22 forks source link

Building Phobos with reggae #20

Open wilzbach opened 8 years ago

wilzbach commented 8 years ago

Following-up on the forum discussion - how far is your progress on a potential replacement of the Makefiles?

atilaneves commented 8 years ago

I could replace the Linux makefile today, possibly the posix one in its entirety (I'd need a Mac and to install FreeBSD to know for sure). The only technical hurdle is Windows - reggae doesn't even compile there due to a compiler bug related to string imports. I've been meaning to fix that myself, since it doesn't seem that anyone cares much.

The main issue isn't technical, it's getting Andrei and Walter on board. If they'd given the green light it'd've been done last year.

Atila

On 30 March 2016 at 14:21, Seb notifications@github.com wrote:

Following-up on the forum discussion http://forum.dlang.org/thread/kjbmzcnhhzlimfkjcsan@forum.dlang.org - how far is your progress on a potential replacement of the Makefiles?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/atilaneves/reggae/issues/20

PetarKirov commented 3 years ago

@atilaneves @kinke I wonder if compiling Phobos with reggae is now possible for Windows as well.

atilaneves commented 3 years ago

At the time the idea was to replace the makefiles with reggae. But now Phobos is technically a dub package so it should work? The advantage would be faster iterative builds I guess.

PetarKirov commented 3 years ago

But now Phobos is technically a dub package so it should work?

TL;DR The motivation for getting rid of the Makefiles is maintainability. The fact that Phobos is available as a Dub package is orthogonal. Also using Phobos as a Dub package is a bad idea, as it's not well tested and it doesn't work across compilers or even with different versions of the same compiler.

Dub doesn't cover all use cases of the Makefiles, whose greatest issue is that are hard to maintain and split between windows and Posix. build.d has been a win for dmd contributors, because everyone knows D and can understand, fix, extend and improve it. Also in the process it solved various bugs that the old build system had and in general helped delete some of the old tanged mess that was there. We could re-use it for druntime and phobos, or we could replace all Makefiles and build.d files with reggae. This is even more true for dlang.org, where the build process is nothing short of a Rube Goldberg contraption.

kinke commented 3 years ago

As a side note, LDC doesn't use the upstream Makefiles, we have our own (involved) CMake script. Porting all of its logic to reggae would presumably be possible but also surely be quite an effort (e.g., it's building the LTO libs and normal libs at once, producing a binary object file and an LTO object file at once).

What complicates matters upstream on Windows is the 32-bit OMF build and the according C parts of druntime/Phobos. The current C(++) reggae support on Windows is restricted to MSVC environments, and I have no plans whatsoever to add exotic DMC platform support.

PetarKirov commented 3 years ago

As a side note, LDC doesn't use the upstream Makefiles, we have our own (involved) CMake script.

I'm hoping we can have shared build system that serves LDC just as well DMD. I'd like to include also GDC, I don't know how feasible this, given that it's part of GCC.

The current C(++) reggae support on Windows is restricted to MSVC environments, and I have no plans whatsoever to add exotic DMC platform support.

Well, the question is which is easier? If build.d already does this, then it's sounds like using it, instead of reggae may be easier. Then there's the question of supporting *BSD, macOS and Android.

Porting all of its logic to reggae would presumably be possible but also surely be quite an effort (e.g., it's building the LTO libs and normal libs at once, producing a binary object file and an LTO object file at once).

My main motivation, at least for upstream, is better maintance through simplification. (A richer language / library moves complexity from users' code it itself).