On 06/01/2015 03:59 PM, Nick Sabalausky wrote:
> On 06/01/2015 03:46 PM, Andrei Alexandrescu wrote:
>>
>> rdmd could collect dependencies while performing the actual compilation.
>> Then, if the dependencies are stable (compare with the saved ones), all
>> done in one run. Otherwise, discard the output and rebuild.
>>
>
> Hmm, actually, that's a good idea.
>
>> This can be implemented today. Would you want to work on it?
>>
>
> I've gotten rusty on RDMD's internals, but I'll take a look, see what I
> can manage.
>

Unfortunately, I've hit a bit of a problem: "dmd -v" doesn't emit an "import  module_name (path/to)" line for imports that were provided on the command line.

Aside from the minor issue of it complicating parts of the code, this makes it impossible (AFAICT) to distinguish between "the deps have not changed" vs "a former dep is no longer imported and should no longer be compiled".

On 2015-06-01 20:39, Nick Sabalausky wrote:

> Unlike rdmd, dub always tries to compile all sources regardless of
> whether they're actually imported. This has been a constant source of
> problems for me, including breakage of conditional importing under
> various circumstances.

Isn't that the only way to compile it if the project is a library? without having to use workarounds like create a new module which imports all other modules.

-- 
/Jacob Carlborg

On 2015-06-01 20:03, Johannes Pfau wrote:

> Create a package format: .dlib (simply a renamed .tar.xz)
> Contents:
>     - PACKAGEINFO //meta information (version)
>     - include/*   //include files
>     - doc/*       //documentation in standard format for IDEs
>     - lib/dmd/libfoo.a
>     - lib/gdc/libfoo.a
>
> Write a small tool xdmd. Implement:
>     //simply move to /usr/share/dlib/libfoo/version/
>     //or ~/.share/dlib/libfoo/version/
>     xdmd --install libfoo.dlib
>     Note: when installing using a systems package manager, packages
>     could be installed in the same way: pacman -S libfoo could call xdmd
>     --install.
>
>     //extract /usr/share/dlib/libfoo/0.9.3/libfoo.dlib
>     //to temporary directory. Pass link and include flags and
>     //rest of arguments to dmd
>     xdmd --library=foo:0.9.3 test.d
>     //directly use local package
>     xdmd --library=libfoo-0.9.3.dlib test.d
>
> This is essentially are very slimmed down dub. Would be a nice weekend
> exercise to write such a tool.

So, a package manager ;). I tried that, but people were complaining that I used Ruby for the meta information and that binary packages would cause problems. Then Dub came and I gave up on that project.

-- 
/Jacob Carlborg

On 2015-06-01 16:49, Jonathan M Davis wrote:

> And this is when Jacob Carlborg chimes in and says "I told you so." ;)
> His favorite complaint about dub has always been that it combined
> package management and the build tool into one.

:)

-- 
/Jacob Carlborg

On 2015-06-01 18:56, Dicebot wrote:

> Though it is hard to invent a package management for interpreted
> language that is not insane. It is much better with native ones because
> runtime dependencies are separated from development dependencies.

Rubygems supports development dependencies.

-- 
/Jacob Carlborg

On 2015-06-01 17:16, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> Since this thread seems to have turned into a wishlist for dub features,
> I'm going to add one:
>
> Undeprecate dependencies on git branches. They are really not different
> from dependencies with fuzzy "~>" versions. For both, the exact selected
> version can be stored in dub.selections.json.

That's a good point, as long as people understand how to use dub.selections.json [1]. But I would rather not allow branches in the registry. I would prefer that a git URL could be added directly to dub.json instead.

[1] https://github.com/github/gitignore/pull/1444

-- 
/Jacob Carlborg

On 2015-06-01 20:49, Steven Schveighoffer wrote:

> I'm not defending DIP11, just that the fact that it could be done
> without requiring an extra "dependencies" file.

One usually needs a file to set all compiler and linker flags and other kinds of configurations. Dub allows you to do this as well in cross-platform way. So when you already have all that, just put the dependencies there and be done with it.

-- 
/Jacob Carlborg

On Mon, 01 Jun 2015 11:59:12 +0000, extrawurst wrote:

>> dub as a build tool sux. no need to discuss that, it simply sux.
> 
> why do you think it sucks ?

'cause it's not more than a simple script in it's core. it can't do good conditional builds, it can't track dependencies for generated files or non-D code, and so on. it's "rdmd with some bells and some features stripped".

this is fine for simple pure D projects, but for complex projects one have to use supplement build tool. and if we have *two* build tools in use, it's logical to remove one that is more tied to the language. and it's dub.

so while it's ok to use dub to build simple things, it's not a good build system. my k8jam, while can't do "consolidated" (i.e. non-separate ;-) builds, can build D code with C/C++ libraries (which are built from source too), generate files, track dependencies, do 'configure' work, allows "dlang.require" operators with dependency tracking between libraries and so on. it can't download libraries, though -- i choose to not implement that, hoping that dub can fulfill that role.

On Mon, 01 Jun 2015 13:11:42 +0000, Adam D. Ruppe wrote:

> One of the things I really like about D is how modules are encapsulated into individual files. The code is there, the documentation is there, the tests are there. No separate headers or anything else.

i like this too.

> But even if I don't use it myself, it would be kinda nice if the repository could handle my files just so I can toss it up there and not have to answer questions about that anymore. I'd be willing to add them all individually to the repo, even listing the dependencies manually if I had to (tip: make this a web form that I can just submit to add stuff to it, no json upload).... but I'm not willing to separate my little repo into 25 other repos and separate my folder into 125 other folders to be added to it.

yep. i don't feel like splitting my IV repo to alot of individual repositories. quite the contrary, i'm moving modules from separate repositories to IV when they are ready. some of IV things are perfectly usable with vanilla, so they can go to code.dlang.org, but... but there is no way to do that now.

On Mon, 01 Jun 2015 16:05:17 -0400, Steven Schveighoffer wrote:

> A protocol to be used between dmd and dub (or any other package fetcher)
> would be a good first step.

that was the thing i once proposed. see, we have a powerful scripting language inside DMD: D! yet we never used all it's power to do something really exciting -- like, for example, preparing command lines for external package fetching tool and parsing the answers. instead of providing a simple module for that, it all goes to be hardcoded.

i extended CTFE engine with simple file i/o functions and "system" call with config-defined executables (something like sudoers list) just to see if it will be usable. and it's surprisingly fun even with all the limits and without hooks for module imports and so on.

this system can be extended to allow writing arbitrary subcommands (like git). just import the corresponding subcommand module, if any, and CTFE it's invocation point. bingo! the system that can be extended without recompiling the compiler. and user can add subcommands on per-project base!

sadly, this seems to get no "wow!"s. :-(