search

premake / premake-core

Premake
https://premake.github.io/
BSD 3-Clause "New" or "Revised" License
3.22k stars 620 forks source link

Drop gmake module in favor of gmake2 #1099

Open tdesveauxPKFX opened 6 years ago

tdesveauxPKFX commented 6 years ago

As #1094 is resolved, let's keep the discussion going on this.

Let's list what is left to do first:

That's all I know of.

I have a fix for the NoPCH so I will make a PR soon.

I can look into the D module but it would take me some time as I never used it nor D.

samsinsane commented 6 years ago

I'm somewhat in favour of just dropping the Makefile support in the D module. gmake2 has been in core since June 2017 (#803), and the replacement was first floated in June 2016 (#516). That's quite a long time for absolutely no movement, people have found time to update and fix the Visual Studio support in the D module, but not the Makefile support?

If someone ports it, that's great - but I don't think we should spend our limited time on porting it. Just my current feelings on the matter.

ratzlaff commented 6 years ago

how feasible is it to have the current gmake module moved completely into the D module?

tdesveauxPKFX commented 6 years ago

@samsinsane I don't know how many people rely on the D module with gmake so I wouldn't just drop it. Also, I think it would be a good use case to open up gmake2 more to additional languages.

@ratzlaff I guess you'd "just" need to implement the D overrides in gmake then merge them. However, that would be the worst solution by far.

When I say "drop the gmake module", I mean move it to it's own repository (gmake_legacy or something) and remove it from premake-core. That way we can patch the D module to use the "legacy gmake" until it is ported to gmake2.

In any case, I think we should first release an alpha13 that include a warning that gmake will be dropped. Last release was 6+ month ago and giving a heads up so that people can look into gmake2 seems like a good idea to me.

tdesveauxPKFX commented 6 years ago

I looked into porting the D module and I'm now inclined to dropping it.

The only changes I saw looks more like people trying to adapt it when they are doing something elsewhere. I wasn't able to generate a simple Makefile.

The gmake action is either not maintained for quite some time or I'm doing something really wrong here.

I do not mind doing the work if someone can provide me an example project using Premake and D (an Open Source project would be perfect as a "production ready" example).

TurkeyMan commented 6 years ago

Do it.

That said, the short of this problem is, there's a deficiency in gmake2 which D would depend on, but also comes up for me frequently in terms of other rules; we have no way to express a many:1 build output relationship. Current rules can do src-file->output-files; rules are applied to each source file, and produce one (or more) output files per source file. D can build this way, but it's more usual to collect the source files into a single invocation of the compiler, effectively many-source-files->one-output-file. I think this is a concept we need to express generally in rules, since I have run into other cases where custom rules have wanted to express this same problem.

An interesting observation is that this is the exact pattern used by the linker (all-objects->one-exe), which we basically just hard-code a special path for. If we generalise this concept so rules can specify that they operate this way, then the linker can be refactored into a normal rule. (also, D will work with gmake2)

TurkeyMan commented 6 years ago

The gmake action is either not maintained [...]

It's this. It's old and out of date. We definitely need to switch to gmake2. But yeah, to support D (and other languages and certain custom rules) in gmake2, it requires expressing many:1 rules like I say above...

tvandijck commented 6 years ago

I think if we generalized more around rules, and indeed allowed many:1 and 1:many rules, we could basically express all types of builds in premake. It's how C# and F# build as well, you give the compiler the full set, and not just one file.

But I also think that linking is currently dealt with completely implicitly in premake, and that might have to change. but I'm not so sure how easy it would be to explain such concepts to a vcxproj file.

TurkeyMan commented 6 years ago

I want to move forward on this issue (many:1 rules). In VS, for linking, .NEt stuff, and for D (via custom logic in the dlang MSBuild stuff) both cases are supported intrinsically. We can detect and hook those cases in the VS backend... but generalising it for VS might be tricky.

In just those supported cases, we could remove a lot of hard-coded mischief in the premake backends.

We don't actually need to generalise it in the VS backend to be useful though... first hurdle is finding a way to express such a rule in premake. If we can agree on some way to express such a rule, then we can stitch it in where it's supported, and in this case, we can close this issue ;)

TurkeyMan commented 6 years ago

Immediately useful cases:
We could express 'linker', 'dynamic linker', 'archiver/static lib tool' as normal rules for "*.exe"/"*.dll"/"*.lib" files, etc, eliminating a lot of hard-coded logic in the back-end.
We could express the .NET build structure, and automatically support .NET makefiles and other benefits, and there's quite some hard-coded supporting logic that we could remove.
This issue would also resolve.

nickclark2016 commented 2 years ago

Hey, I wanted to just poke on this and see if there's still a desire to port the D module to gmake2? I'm personally inclined to drop it at this point from premake-core and have it move to an external module.