Can we stop maintaining both git submodules + dub.json?

[wilzbach]

At the moment we have to maintain the dub.sdl's + the git submodules for all DScanner/libdparse tools. This is rather painful, because while dub does fetch the latest patched version of the dependencies (well, except for -alpha tags), git submodules is just a fixed git commit hash. While @skl131313 has written a bot to help with this maintenance work, but it still requires a lot of effort to do something that dub would do out of the box for us.

Hence, my question (1): are there still valid uses for the gitsubmodules?

Also (2) if we already have this discussion, it would be great if we could stop tagging bug fixes as -alpha.X - that's how SemVer is intended to be used.

CC @dlang-community/dcd-dsymbol-libdparse @dlang-community/dscanner

[WebFreak001]

I'm more a fan of dub than submodules too, sometimes you forget to update them when pulling and in my experience using the makefile (even with -j) was always a lot slower than dub, even when dub recompiled everything. (just checked dfmt: makefile 24s, dub 8s) (dub builds debug by default, make release)

[ghost]

I always use make or bat file. I'm against removing this way of building, although i recoqnize that the maintenance is a slight problem (let's not forget that DUB jsons were added after).

[skl131313]

in my experience using the makefile (even with -j) was always a lot slower than dub, even when dub recompiled everything. (just checked dfmt: makefile 24s, dub 8s)

What commands are you using to compare? Cause by default the makefile creates a release build, and by default dub creates a debug build with no optimizations. I just tested the make files and dub, they are pretty much identical. Dub was 1-2 seconds faster. Part of that might be that -j won't do much for the makefile cause all the source files are compiled by a single command. Dub might compile the sources in parallel.

Did a quick test and separating the source to be compiled individual and then running make with -j makes the compile time go a few seconds faster than dub.

Personally I don't really like dub, I don't use it when possible. Especially for development, having the source files for the other projects in the directory is convient. If you need to work on one of the submodules you can just grab DCD or any other repo. Make modifications in source, then recompile it and test the changes made. With dub the package is grabbed and put somewhere else. I think there's a way around it with some of the commands, but it's a pain to try and just satisfy some build config rules. The changes to dub that you would only want to be done to one project are instead done globally for dub, I think. It's been a while since I used it.

[UplinkCoder]

@skl131313 does the dub specify -O ? If not, they are not identical.

[skl131313]

I think it does for release builds, but that isn't the default you have to do:

dub build -b release

[skl131313]

Also (2) if we already have this discussion, it would be great if we could stop tagging bug fixes as -alpha.X - that's how SemVer is intended to be used.

I agree with this, pretty much every tag is beta/alpha anyways. If one gets released that isn't a beta or alpha it will pretty much never be used anyways. Should we just create new tags for everything with the current versions they are at, even if there is nothing new?

[ghost]

We can start updating only the "patch" component instead of the additional one. Hackerpilot used alpha and beta before the move to the organization, then we've followed. More rarely the minor component have to be updated, like the other day when a breaking change was merged in dparse.

[ghost]

I've changed my mind for D-Scanner. I've just check dub --build=unittest which works fine, so the make file and the bat can be blindly dropped.

For DCD it's still useful because dsymbol is hard to work with so it's convenient to be able to test the changes in the submodule. Also the test suite would be rather hard to convert.

[ghost]

This requires dub packages server to be very stable. I've read good feedback on the forum latest two months but right now it doesn't work.