On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev
wrote:
In contrast, Dub's default modus operandi is to blindly send to
the compiler all *.d files found in the "src" folder, whether
they're actually used or not. Not only can this be slower if
not all modules are always used, but it also won't work if the
source code contains multiple entry points, forcing you to
write complicated configuration files (i.e. do the computer's
work for it).
To be more specific, dub won't let you compile a project with
multiple definition of a function. How is that a liability ?
Is rdmd able to build static and dynamic library ? If so, does it
ignore files that are not imported anywhere ?
1b. rdmd and D's search path
rdmd does not have any additional parameters to set up for
where it needs to look for source files, because it relies on
the compiler's search mechanism. Thus, if you can build your
program with rdmd, "dmd -o- program" will succeed, and usually
vice versa.
In contrast, Dub builds its own search path using its JSON
configuration files, and has no equivalent of "dmd -o-".
I don't see any downside here.
There is no simple way to syntax-check just one file in a
project when using Dub. I rely on this a lot in my workflow - I
configured a syntax-check key in my editor, which I use almost
as often as I save. A syntax check (dmd -o-) is much faster
than a full build, as it skips parsing other parts of the
project, code generation, and linking.
What's your editor ? Mine complains on syntax error.
If you're using vi/emacs, then placing your editor in source/ (or
starting dmd here) would do the trick.
2d. Git vs. Dub
Unfortunately, the above-described approach is not compatible
with Dub:
- Dub packages are generally expected to have their source code
in a "src" subdirectory, although you can set the source
directory to "." in the configuration file.
- When cloning repositories, dub does not preserve the
repository's directory name (so e.g. fruit will be cloned to
~/.dub/fruit-1.0.0/).
Somebody has created a Dub package for my library (excluding
certain packages, due to point 1a above), and the other day
someone complained that it doesn't work with Dscanner, because
of the above issue - the module path "ae.dir.module" does not
correspond to the filesystem path "ae-1.0.1/dir/module.d".
git clone http://github.com/You/repo otherName
breaks that workflow equally. Relying on the name under which
your repo was cloned doesn't seem that robust.
So, in order to start using Dub, I'd need to:
- restructure the directory layout of my library (breaking
change)
- update all projects which use this library to use Dub instead
- give up quick syntax checking
- give up commit-granularity versioning
- begin maintaining JSON configuration files
- begin versioning libraries by hand
- install Dub on all my computers, servers, and virtual machines
No thanks.
- But then your library is self contained and won't break if
someone has another workflow that makes him clone your library
under a different name.
- That's the point.
- Addressed;
- Semver allows you to do much more, as mentionned before;
- It isn't much of a maintainance. You rarely edit dub.json once
the base is set.
- dub rely on git tags for versioning. If you want to do *real*
versioning (and not just "most up to date tag"), you'll still
have to play with branches and submodules.
- Only your dev stations.
Change my view.
Hope I helped :)
