On Mon, 02 Feb 2015 12:54:01 +0000, Atila Neves wrote:

> Unless things have changed significantly or I remember incorrectly, vibe.d depends on C code (libevent), which gets built by dub.

no, it's not build by dub. at least for GNU/Linux it expects to find it already installed.

On 2/2/2015 7:13 PM, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton Wakeling wrote:
>> Well, as long as the requirements are expressed in the form,
>>
>>     "package-name": ">=1.2.3"
>
> This will allow Dub to pick a new major version with incompatible
> changes, no?

"~>1.2.3"
This will constrain it to the range of 1.2.3 ... 1.3.0.

On 2/2/2015 6:34 PM, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 09:25:31 UTC, Mathias LANG wrote:
>> On Monday, 2 February 2015 at 09:03:56 UTC, Vladimir Panteleev wrote:
>>>
>>> Is that so? Won't a security fix entail a version bump, requiring a
>>> change in the requirements file of the parent project? Also, does Dub
>>> really check for updated versions of libraries online, every time a
>>> project is built?
>>>
>>
>> It does.
>
> It actually does a roundtrip every time you build your project???

No. It requires 'dub upgrade'.

On Monday, 2 February 2015 at 11:59:07 UTC, ketmar wrote:
> On Mon, 02 Feb 2015 11:04:29 +0000, Tobias Pankrath wrote:
>
>> On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
>>> On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
>>>>
>>>> [snip]
>>>
>>> I agree with basically everything you said.
>>> I'll add, I have no use for (and no way to use) dub because I depend on
>>> cross-language build configurations.
>>> If my D project depends on a C lib, then what am I supposed to do to
>>> make dub useful for me?
>>>
>>>
>> I don't understand, can't you just use a C build tool for the C lib and
>> link to it via dub?
>
> and then we have TWO build tools. and a script that invokes one, and then
> another. THREE build tools. see the pattern?

Well, we wont convince every C programmer out there whose library one wants to use to switch to dub.

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 :)

On Mon, 02 Feb 2015 13:14:57 +0000, Tobias Pankrath wrote:

> Well, we wont convince every C programmer out there whose library one wants to use to switch to dub.

especially when dub cannot build C code.

On Monday, 2 February 2015 at 13:25:57 UTC, Mathias LANG wrote:
> To be more specific, dub won't let you compile a project with multiple definition of a function. How is that a liability ?

You can't have more than one main() function.

Some packages contain more than one entry point (programs / executables).

In my case, my library allows selecting an entry point based on the nature of the program (console/GUI) and the platform. The program only imports one of these. Vibe does something similar, but it has only one entry point.

> Is rdmd able to build static and dynamic library ?

Yes.

> If so, does it ignore files that are not imported anywhere ?

Yes.

> I don't see any downside here.

The downside is dmd -o- doesn't work.

> 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.

"syntax check" was not meant literally. Can your editor instantiate imported templates, too?

FYI, my editor's D syntax highlighting is probably more extensive than any others':

https://github.com/colorer/Colorer-schemes/blob/master/hrc/hrc/base/d.hrc

> 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.

The distinction is that you have to go out of your way to break it. Dub not just breaks it by default, but there is no simple way to work around it, either.

> - 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.

So Dub protects people from shooting themselves in the foot by cutting their feet off? How nice.

> - 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.

Yay, more buttons to press! When I could actually be getting things done instead.

> Hope I helped :)

Sorry, not even close.

On Monday, 2 February 2015 at 13:42:19 UTC, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 13:25:57 UTC, Mathias LANG wrote:
>> To be more specific, dub won't let you compile a project with multiple definition of a function. How is that a liability ?
>
> You can't have more than one main() function.
>
> Some packages contain more than one entry point (programs / executables).
>
> In my case, my library allows selecting an entry point based on the nature of the program (console/GUI) and the platform. The program only imports one of these. Vibe does something similar, but it has only one entry point.
>

You can do this with dub. You selectively include or exclude files/directories on a per-configuration basis.

Overall - while you do have some valid complaints - you don't seems to know dub particularly well. Maybe you do, but it's not coming across.

On Monday, 2 February 2015 at 14:06:46 UTC, John Colvin wrote:
> You can do this with dub. You selectively include or exclude files/directories on a per-configuration basis.

I have addressed this in my initial post.

> Overall - while you do have some valid complaints - you don't seems to know dub particularly well. Maybe you do, but it's not coming across.

I don't understand what point you're trying to say here. The thread starts with the line:

>> I don't use Dub

Andrej and I seem to have a very similar workflow, as the additional experience he shared would affect me as well if I tried to switch to it.

On Monday, 2 February 2015 at 13:42:19 UTC, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 13:25:57 UTC, Mathias LANG wrote:
>> To be more specific, dub won't let you compile a project with multiple definition of a function. How is that a liability ?
>
> You can't have more than one main() function.
>
> Some packages contain more than one entry point (programs / executables).
>
> In my case, my library allows selecting an entry point based on the nature of the program (console/GUI) and the platform. The program only imports one of these. Vibe does something similar, but it has only one entry point.

You can do that using configuration sections:
http://code.dlang.org/package-format#configurations

>> Is rdmd able to build static and dynamic library ?
>
> Yes.
>
>> If so, does it ignore files that are not imported anywhere ?
>
> Yes.
>

I don't see how this is a feature. I want all my file parsed and put inside the archive.

>> I don't see any downside here.
>
> The downside is dmd -o- doesn't work.

It works when you're in source. No difference.

>> 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.
>
> "syntax check" was not meant literally. Can your editor instantiate imported templates, too?
>

I'd like it too, but not ATM :(
Is the working directory option working for you ?

>> 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.
>
> The distinction is that you have to go out of your way to break it. Dub not just breaks it by default, but there is no simple way to work around it, either.
>

If you go out of dub's way, you might break it. The same happen when someone goes out of your workflow. Is running dmd -o- from ./project/source instead of ./project/ impossible with your setting / IDE ?

>> - 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.
>
> Yay, more buttons to press! When I could actually be getting things done instead.

Want to track a branch: ~branchName
Want to track a specific commit: == x.x.x
want to track a bounded commit range: ~> / >= <=
Want to track an unbounded commit range: >=