Re: DUB 0.9.21 beta 1

[Kapps]

On Wednesday, 11 December 2013 at 22:13:59 UTC, Kapps wrote:
I noticed that the main file generated seems to already support 
tested integration automatically which I find quite nice. 
Unfortunately it seems that tested is not actually following 
imports so both the above sample and the auto-generated main 
result in 0 tests being run as test_main does not directly 
contain any tests. I've tried looking in to fixing this, but 
it's proving a bit more tricky than expected and I won't have 
much time for the next couple of days. Essentially, with 
"static if (__traits(compiles, { auto tup = 
TypeTuple!(__traits(getMember, composite, M)); }))" I don't 
believe that that's ever true as assigning to tup like that is 
an error. Changing that to check if the getMember succeeds will 
then get past that, but now the recursive calls for 
runUnitTestsImpl will operate on the return type of methods as 
__traits(getMember, T, ) returns the result of 
invoking the method and not the method itself. I'm not sure how 
to pass in an alias to the actual method rather than to the 
return type.


Ah, I think I'm mistaken. What I assumed was that it was handling 
the return type of the function may have just been that it was 
going over aliases instead (which in this case would have been an 
alias to ulong and such, causing the above problems).

Re: DUB 0.9.21 beta 1

[Kapps]

On Wednesday, 11 December 2013 at 09:51:37 UTC, Sönke Ludwig 
wrote:
The latest GIT master version now works without requiring a 
main file.
Regarding integration with "tested", what should work now is to 
import
the automatically generated module "test_main" and use that as 
the

testing root:


Awesome. :)

I noticed that the main file generated seems to already support 
tested integration automatically which I find quite nice. 
Unfortunately it seems that tested is not actually following 
imports so both the above sample and the auto-generated main 
result in 0 tests being run as test_main does not directly 
contain any tests. I've tried looking in to fixing this, but it's 
proving a bit more tricky than expected and I won't have much 
time for the next couple of days. Essentially, with "static if 
(__traits(compiles, { auto tup = TypeTuple!(__traits(getMember, 
composite, M)); }))" I don't believe that that's ever true as 
assigning to tup like that is an error. Changing that to check if 
the getMember succeeds will then get past that, but now the 
recursive calls for runUnitTestsImpl will operate on the return 
type of methods as __traits(getMember, T, ) returns 
the result of invoking the method and not the method itself. I'm 
not sure how to pass in an alias to the actual method rather than 
to the return type.

Re: Build Master: Progress toward 2.065

[Dicebot]

On Wednesday, 11 December 2013 at 09:13:05 UTC, David Nadlinger 
wrote:
This collection of "anything" includes local tracking branches 
people might already use, a simple "git pull" won't work 
anymore. Thus, it's very much not just an abstract 
inconvenience – it might be trivial to fix, but less Git-savy 
people might not immediately know how to handle the situation.


That may sound very impolite but last thing I want to care about 
are "less Git-savy" people that refuse to learn. Resetting local 
tracking branch is common part of normal git workflow. It is not 
even advanced stuff. When I am speaking about "anything" I imply 
"anything released / deployed" - there is no practical value in 
adhering to local development branch history other than removing 
requirement to be familiar with `git reset` basics. If someone 
among developers participating in 2.065 is not familiar with it, 
it is a major problem in those developers, not in git flow.


I am continuously outraged by the fact that someone may find 
acceptable to willingly ignore one of most important tools 
involved in development / release process.

Re: DUB 0.9.20

[Jakob Ovrum]

On Wednesday, 11 December 2013 at 09:47:27 UTC, Sönke Ludwig 
wrote:
The current GIT master version now outputs a clearer message, 
stating

that the existing binary from ".dub/build/.../" is used. It also
suggests to use "--force" to force a rebuild.


Nice.

The .dub/build/ folder is purely meant for DUB's built-in build 
system
(maybe a better name would be "cache" or "build-cache"). IDE 
projects
and external tools shouldn't ever look at it. The final build 
result
will be located in the specified "targetPath", which is where 
every

other entity except the build system should expect it.


That was exactly my point. They need to be able to live 
side-by-side in the targetPath directory. You replied and told me 
they do live side-by-side in the cache directory, which I don't 
think is relevant.


I don't get this. The copying will be done by dub automatically 
and IDE
projects will usually use their own way of storing different 
build type
results. Are there any other tools you are thinking about which 
depend

on the presence of multiple build types?


From your reply I assumed you meant adding something like a 
post-build command to copy the debug binary from the .dub/build/ 
directory to the targetPath directory if I wanted to have both 
release and debug binaries exist in targetPath simultaneously.


Consider a simple makefile that depends on 
dependency/lib/libname.a for release builds and 
dependency/lib/lib/libname-d.a for debug builds, or an IDE 
project that's configured similarly, or a zip script that needs 
to include both etc. The scenarios are endless, it's quite common 
practice.


They are just different "build types" which pass different 
flags to the
compiler. Everything else stays the same. The build cache is 
briefly

described in
https://github.com/rejectedsoftware/dub/wiki/Separate-compilation-and-caching-of-dependencies
- but assuming it does its job right, it shouldn't change the 
semantics

of the (re)build process.


Right, if there was a build-type suffix and targetName supported 
it, I could do:


"targetName-debug": "mylib-d"

Regarding the suffixes (or pre-/infixes), the foremost issue is 
how to
suit everyone's taste ("d"/"debug"/"dbg") without going crazy 
for the
required configuration on package.json. That plus that I 
haven't yet
understood why this is really needed to solve the problem. I'd 
by far
prefer a simple (to the outside) solution that "just works" 
without any

required configuration.


A reasonable default helps with the "just works" factor for new 
projects, but existing projects need the suffix to be 
configurable so it can be backwards-compatible. It's also more 
practical to let users choose what suffix to use rather than 
pursuing the "ultimate" suffix for satisfying users' taste.

Re: DUB 0.9.20

[Sönke Ludwig]

Am 09.12.2013 17:52, schrieb Jakob Ovrum:
> On Friday, 6 December 2013 at 19:57:17 UTC, Sönke Ludwig wrote:
>> Am 06.12.2013 19:40, schrieb Jakob Ovrum:
>>> On Friday, 29 November 2013 at 17:02:22 UTC, Sönke Ludwig wrote:
  - Builds are now cached and only rebuilt when necessary for "dub
 build"
and "dub run".
>>>
>>> Deleting the output binary and then immediately running `dub build`
>>> again fails horribly here; it seems to think the binary is up to date
>>> even though it doesn't even exist. (Windows/DMD/x86, library target)
>>
>> You need to delete the one in .dub/build/, the one in the target
>> directory is just a copy of that one. BTW there is now a "dub build
>> --force" switch, which forces a recompilation, and a "dub clean" command
>> will also be added later.
> 
> I actually tried `dub clean` as a guess, so that would be appreciated.
> But I have to say it's unintuitive behaviour compared to something like
> `make`. Users should not be concerned with the contents of a hidden
> directory. Deleting the output binary to force a rebuild is intuitive to
> me and probably a lot of other programmers. Perhaps just make it copy
> the up-to-date binary from the .dub/build directory to the output
> directory, displaying a note about it, possibly with a suggestion to use
> `dub clean`.

The current GIT master version now outputs a clearer message, stating
that the existing binary from ".dub/build/.../" is used. It also
suggests to use "--force" to force a rebuild.

> 
>> They currently live in parallel in different sub folders of .dub/build/
>> and switching between different builds is just a matter of a single copy
>> of the target file, as long as the builds are up to date. I didn't yet
>> have issues with this approach, but on the other hand not much thought
>> has gone into this part, yet.
> 
> Tools like makefiles, IDE project files and indeed Dub itself cannot
> depend on the contents of the .dub/build directory. Having them exist in
> parallel is only useful for dependency management if they can actually
> be referenced.

The .dub/build/ folder is purely meant for DUB's built-in build system
(maybe a better name would be "cache" or "build-cache"). IDE projects
and external tools shouldn't ever look at it. The final build result
will be located in the specified "targetPath", which is where every
other entity except the build system should expect it.

> 
> "Switching between the builds" is not useful when the whole point is
> that they should be able to exist at the same time, so that debug builds
> can use debug binaries, and release builds use release binaries, without
> any non-trivial fuzz in between such as copying, which is a royal pain
> with many tools when you're trying to write platform-independent projects.

I don't get this. The copying will be done by dub automatically and IDE
projects will usually use their own way of storing different build type
results. Are there any other tools you are thinking about which depend
on the presence of multiple build types?

> 
> Is there a particular reason why `targetName` doesn't support suffixes?
> And is there a suffix to differentiate between debug and release builds?
> I currently have no idea how Dub deals with the debug/release
> distinction at all, I can't find any documentation for it.

They are just different "build types" which pass different flags to the
compiler. Everything else stays the same. The build cache is briefly
described in
https://github.com/rejectedsoftware/dub/wiki/Separate-compilation-and-caching-of-dependencies
- but assuming it does its job right, it shouldn't change the semantics
of the (re)build process.

Regarding the suffixes (or pre-/infixes), the foremost issue is how to
suit everyone's taste ("d"/"debug"/"dbg") without going crazy for the
required configuration on package.json. That plus that I haven't yet
understood why this is really needed to solve the problem. I'd by far
prefer a simple (to the outside) solution that "just works" without any
required configuration.

Re: DUB 0.9.21 beta 1

[Sönke Ludwig]

Am 09.12.2013 18:29, schrieb Kapps:
> On Monday, 9 December 2013 at 12:46:00 UTC, Kapps wrote:
>> I was looking for something similar to dub test and am glad to see it
>> added, but I can't seem to figure out how to get it to do anything at
>> all.
> 
> Okay, it seems that this was just an issue with the beta. Building from
> git master allows me to run "dub test" on an executable or a library
> that has a main function within app.d. It would be nice to have an
> automated way of running unit tests for all modules within a library
> with a main file automatically generated. Even more awesome if there was
> a way to integrate with tested to perform the tests. Perhaps for the
> latter I could determine all files in the library with dub describe,
> generate an app.d that calls tested's unit test runner on each, and then
> put that app.d inside the library's source folder before invoking dub test.

The latest GIT master version now works without requiring a main file.
Regarding integration with "tested", what should work now is to import
the automatically generated module "test_main" and use that as the
testing root:

---
import test_main;

shared static this()
{
import core.runtime;
Runtime.moduleUnitTester = () => true;
}

void main()
{
enforce(runUnitTests!test_main(new ConsoleTestResultWriter), "Unit
tests failed.");
}
---

Re: DUB 0.9.20

[Sönke Ludwig]

Am 06.12.2013 22:55, schrieb Mathias Lang:
> Great work, thank you Sönke !
> 
> 
> 2013/12/6 Sönke Ludwig  >
> 
> You need to delete the one in .dub/build/, the one in the target
> directory is just a copy of that one. BTW there is now a "dub build
> --force" switch, which forces a recompilation, and a "dub clean" command
> will also be added later. 
> 
> 
> Did you ever consider letting users add their own "recipe" (in Makefile
> terminology).
> ie, let them extend dub the same way you can extend git: one would put a
> bash / D / FancyScriptLanguage script under [~/].dub/whatever/deploy,
> and calling dub deploy would call that script, passing it the
> package.json data.

Incidentally, I've planned to look into something like this (for
deployment), too, a few days ago. In the beginning, there was also the
plan to provide a mode to run an external tool using "dub tool
". The tool would then receive a bunch of environment
variables that describe the current package.

But regarding the git-like extensibility, I'm not sure if it's not
better to let extensions rather be separate tools ("dub-deploy") to
avoid naming conflicts or backwards compatibility issues between the
core package and extensions.

>  > Also, it would be nice if there was a way to output to a different
> 
> > target name for debug vs release builds of a library. It's quite
> common
> > to have both live side-by-side, with the debug builds
> differentiated by
> > a suffix -d or similar.
> 
> That's something I found myself missing alot in D. Those little trick
> aren't much of a pain to implement on the tool side, but they're
> definitely a huge gain on the user side.

Do you actually need to have both binaries at the same time in the same
directory, or would copying it there just before starting up the
application also be enough? I'm asking because there will probably be no
single schema that all people will be happy with and considering the
issues that arise from that, I'd rather avoid that feature if the same
goals can be achieved differently.

Re: Build Master: Progress toward 2.065

[David Nadlinger]

On Tuesday, 10 December 2013 at 13:43:51 UTC, Dicebot wrote:
It is not a problem to reset local branches on rare occasions 
like this one, whatever developer count is. Reason why rebasing 
of public branches is discouraged is not some abstract 
inconvenience of collaboration - it is the fact that commit 
hashes change in history and anything that has been pointing to 
part of history that got rewritten will be broken (especially 
important if, for example, commit hashes are embedded into 
deployed builds).


This collection of "anything" includes local tracking branches 
people might already use, a simple "git pull" won't work anymore. 
Thus, it's very much not just an abstract inconvenience – it 
might be trivial to fix, but less Git-savy people might not 
immediately know how to handle the situation.


David