Re: DUB 0.9.20
Am 06.12.2013 22:55, schrieb Mathias Lang: Great work, thank you Sönke ! 2013/12/6 Sönke Ludwig slud...@outerproduct.org mailto:slud...@outerproduct.org 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 executable. 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: DUB 0.9.20
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.20
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
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`. 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. 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. 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.
Re: DUB 0.9.20
On 2013-12-06 22:55, Mathias Lang wrote: 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. I think that would be nice to have. -- /Jacob Carlborg
Re: DUB 0.9.20
On 03/12/2013 13:44, Sönke Ludwig wrote: Am 03.12.2013 13:47, schrieb Bruno Medeiros: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub upgrade should be the right call. Possibly with --root=path/to/package or dub upgrade pkgname:subpkgname --root=path/to/package. It's not clear from the name, but yeah, does the trick! -- Bruno Medeiros - Software Engineer
Re: DUB 0.9.20
Am 06.12.2013 13:57, schrieb Bruno Medeiros: On 03/12/2013 13:44, Sönke Ludwig wrote: Am 03.12.2013 13:47, schrieb Bruno Medeiros: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub upgrade should be the right call. Possibly with --root=path/to/package or dub upgrade pkgname:subpkgname --root=path/to/package. It's not clear from the name, but yeah, does the trick! The only use case that usually makes sense for it is to upgrade packages. All other commands should implicitly fetch the required packages, including dub describe, so no explicit dependency fetching is necessary.
Re: DUB 0.9.20
On 06/12/2013 13:58, Sönke Ludwig wrote: Am 06.12.2013 13:57, schrieb Bruno Medeiros: On 03/12/2013 13:44, Sönke Ludwig wrote: Am 03.12.2013 13:47, schrieb Bruno Medeiros: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub upgrade should be the right call. Possibly with --root=path/to/package or dub upgrade pkgname:subpkgname --root=path/to/package. It's not clear from the name, but yeah, does the trick! The only use case that usually makes sense for it is to upgrade packages. All other commands should implicitly fetch the required packages, including dub describe, so no explicit dependency fetching is necessary. 'dub describe' is doing no such thing for me. Is that a bug? -- Bruno Medeiros - Software Engineer
Re: DUB 0.9.20
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) In the works for the next version is, among other things, a dub test [2] command which executes unit tests (and possibly other kinds of tests later) using a custom main() function, especially useful for automated testing and testing of libraries without a main() function. It has been said already in this thread, but for library targets it must ignore the lack of a main source file. It should go without saying that libraries generally don't have such a thing. --- 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. --- I added a couple of my projects to the package repository[1][2]. [1] http://code.dlang.org/packages/dirk [2] http://code.dlang.org/packages/diggler
Re: DUB 0.9.20
On Friday, 6 December 2013 at 18:40:59 UTC, Jakob Ovrum wrote: It has been said already in this thread, but for library targets it must ignore the lack of a main source file. It should go without saying that libraries generally don't have such a thing. It adding such requirement for static libraries much of an issue? It provides quite lot of advantages. Though I guess dub can possibly generate such file on its own.
Re: DUB 0.9.20
On Friday, 6 December 2013 at 19:10:51 UTC, Jakob Ovrum wrote: It's unreasonable for Dub to require users to change the structure of their project It has been doing it since the very beginning and still does.
Re: DUB 0.9.20
On Friday, 6 December 2013 at 19:14:46 UTC, Dicebot wrote: On Friday, 6 December 2013 at 19:10:51 UTC, Jakob Ovrum wrote: It's unreasonable for Dub to require users to change the structure of their project It has been doing it since the very beginning and still does. How so? In the very beginning it was much stricter, but it had the excuse that it was originally a vibe.d-specific utility. Once the scope of the project changed, we got additions like `sourcePaths` which made Dub support a much wider range of project structures. It should be a no-brainer that Dub should impose as few restrictions on users as possible by letting them specify their project structure entirely in package.json.
Re: DUB 0.9.20
Am 06.12.2013 16:39, schrieb Bruno Medeiros: On 06/12/2013 13:58, Sönke Ludwig wrote: Am 06.12.2013 13:57, schrieb Bruno Medeiros: On 03/12/2013 13:44, Sönke Ludwig wrote: Am 03.12.2013 13:47, schrieb Bruno Medeiros: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub upgrade should be the right call. Possibly with --root=path/to/package or dub upgrade pkgname:subpkgname --root=path/to/package. It's not clear from the name, but yeah, does the trick! The only use case that usually makes sense for it is to upgrade packages. All other commands should implicitly fetch the required packages, including dub describe, so no explicit dependency fetching is necessary. 'dub describe' is doing no such thing for me. Is that a bug? Indeed, sorry, I didn't check that. It's fixed on git master.
Re: DUB 0.9.20
Am 06.12.2013 20:10, schrieb Jakob Ovrum: On Friday, 6 December 2013 at 18:55:22 UTC, Dicebot wrote: On Friday, 6 December 2013 at 18:40:59 UTC, Jakob Ovrum wrote: It has been said already in this thread, but for library targets it must ignore the lack of a main source file. It should go without saying that libraries generally don't have such a thing. It adding such requirement for static libraries much of an issue? It provides quite lot of advantages. Though I guess dub can possibly generate such file on its own. It's unreasonable for Dub to require users to change the structure of their project, or add boilerplate to their project, for something as fundamental as building a simple static library. Just to get the facts straight, building a static library works without a main file, just not when --rdmd is used. The only thing added in the beta was the warning message.
Re: DUB 0.9.20
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. In the works for the next version is, among other things, a dub test [2] command which executes unit tests (and possibly other kinds of tests later) using a custom main() function, especially useful for automated testing and testing of libraries without a main() function. It has been said already in this thread, but for library targets it must ignore the lack of a main source file. It should go without saying that libraries generally don't have such a thing. I'll work through that topic in the next days. If nothing requires it, the warning will be removed and dub test will auto generate such a file when needed. --- 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. 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.
Re: DUB 0.9.20
On 2013-12-06 19:55, Dicebot wrote: It adding such requirement for static libraries much of an issue? It provides quite lot of advantages. Though I guess dub can possibly generate such file on its own. This might also cause modules to be more coupled with each other and causing more of the library being included then actually needed. Like what's happening with Phobos. -- /Jacob Carlborg
Re: DUB 0.9.20
Great work, thank you Sönke ! 2013/12/6 Sönke Ludwig slud...@outerproduct.org 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. 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.
Re: DUB 0.9.20
On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? -- Bruno Medeiros - Software Engineer
Re: DUB 0.9.20
On 12/3/2013 9:47 PM, Bruno Medeiros wrote: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub install packageName
Re: DUB 0.9.20
On 03/12/2013 13:00, Mike Parker wrote: On 12/3/2013 9:47 PM, Bruno Medeiros wrote: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub install packageName That only works if packageName is a package in the DUB registry. It won't work for a locally created package. -- Bruno Medeiros - Software Engineer
Re: DUB 0.9.20
On Tuesday, 3 December 2013 at 13:18:13 UTC, Bruno Medeiros wrote: That only works if packageName is a package in the DUB registry. It won't work for a locally created package. You can make dub aware of such a package with: $ dub all-local . ~master In which case, this particular package doesn't need to be dub-installed.
Re: DUB 0.9.20
You can make dub aware of such a package with: $ dub all-local . ~master In which case, this particular package doesn't need to be dub-installed. I meant add-local not all-local.
Re: DUB 0.9.20
On Tuesday, 3 December 2013 at 13:00:06 UTC, Mike Parker wrote: On 12/3/2013 9:47 PM, Bruno Medeiros wrote: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub install packageName It is `dub fetch` now, to remove common confusion. Alias to old name is preserved but undocumented.
Re: DUB 0.9.20
Am 03.12.2013 13:47, schrieb Bruno Medeiros: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub upgrade should be the right call. Possibly with --root=path/to/package or dub upgrade pkgname:subpkgname --root=path/to/package.
Re: DUB 0.9.20
Jordi Sayol wrote: El 30/11/13 02:08, Piotr Szturmaj ha escrit: Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Thanks! Have you considered adding a version number to dub help and/or a --version option? $ dub help prints version on last line: DUB version v0.9.20 This is my dub help output (Windows): http://pastebin.com/0ENFz28V
Re: DUB 0.9.20
Am 02.12.2013 12:25, schrieb Piotr Szturmaj: Jordi Sayol wrote: El 30/11/13 02:08, Piotr Szturmaj ha escrit: Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Thanks! Have you considered adding a version number to dub help and/or a --version option? $ dub help prints version on last line: DUB version v0.9.20 This is my dub help output (Windows): http://pastebin.com/0ENFz28V Oh okay, that's for post-0.9.20. I've rewritten the command line interface code and forgot to add this. Will do now.
Re: DUB 0.9.20
On 30 Nov 2013 01:55, Sönke Ludwig slud...@outerproduct.org wrote: Am 29.11.2013 23:05, schrieb Jonathan M Davis: On Friday, November 29, 2013 18:01:53 Sönke Ludwig wrote: - Running dub --build=ddox runs a local HTTP server that provides the docs instead of generating them all as actual HTML files. Why would that be desirable? I would expect a set of HTML files if generating documentation, and if a server is required to read the documentation instead of just bringing them up in your browser, that's a major usability problem IMHO. If ddox requires a server rather than just working with .html files, that would be a big reason for me to never use it. - Jonathan M Davis You can still use dub build --build=ddox to generate actual HTML files, but using run it will simply skip the generation part and displays the documentation much faster, depending on the size of the project. Great feature of you're working on docs. Probably awesome for bigger projects.
DUB 0.9.20
A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: - Builds are now cached and only rebuilt when necessary for dub build and dub run. - Generated VisualD projects and the output of dub describe now contain import files and string import files in addition to pure source files. - Running dub --build=ddox runs a local HTTP server that provides the docs instead of generating them all as actual HTML files. - Pre-release versions of dependencies (e.g. 1.0.0-rc.1) are now only installed of nothing else matches the version expression, or if dub upgrade --prerelease is used. This is supposed to encourage the use of pre-release versions instead of just working with branches for released packages. - https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md We also have now well over a hundred packages in the registry, 117 at this point [1]! Download at http://code.dlang.org/download In the works for the next version is, among other things, a dub test [2] command which executes unit tests (and possibly other kinds of tests later) using a custom main() function, especially useful for automated testing and testing of libraries without a main() function. [1]: http://code.dlang.org [2]: https://github.com/rejectedsoftware/dub/issues/83
Re: DUB 0.9.20
New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ -- Jordi Sayol
Re: DUB 0.9.20
On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages.
Re: DUB 0.9.20
El 29/11/13 20:37, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages. libphobos2-nn and other packages ending with -nn contains the shared library necessary to run programs linked against them, so for this reason these packages have version on its name, allowing to install multiple versions of the same library. Different case is dmd and development packages -dev. Debian packaging system do not allow to install multiple versions of the same package at same time. i.e. dmd_2.064.2-0_amd64.deb is newer version of dmd_2.063.2-0_amd64.deb, and upgrades it. same with libphobos2-dev_2.064.2_amd64.deb, which replaces libphobos2-dev_2.063.2_amd64.deb by an upgrade. To have multiple dmd versions on your system, you can use the Jacob Carlborg project https://github.com/jacob-carlborg/dvm Regards, -- Jordi Sayol
Re: DUB 0.9.20
On Friday, 29 November 2013 at 20:17:54 UTC, Jordi Sayol wrote: El 29/11/13 20:37, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages. libphobos2-nn and other packages ending with -nn contains the shared library necessary to run programs linked against them, so for this reason these packages have version on its name, allowing to install multiple versions of the same library. OK, I see. Can we have different DMD packages with different DMD names? For example, can we have `dmd-63` and `dmd-64` at the same time? So, the `dmd` is simple alias to the latest DMD version. Sorry if I miss something, but it looks like possible solution. To have multiple dmd versions on your system, you can use the Jacob Carlborg project https://github.com/jacob-carlborg/dvm Yes, I know. But packages save some time.
Re: DUB 0.9.20
On Friday, November 29, 2013 18:01:53 Sönke Ludwig wrote: - Running dub --build=ddox runs a local HTTP server that provides the docs instead of generating them all as actual HTML files. Why would that be desirable? I would expect a set of HTML files if generating documentation, and if a server is required to read the documentation instead of just bringing them up in your browser, that's a major usability problem IMHO. If ddox requires a server rather than just working with .html files, that would be a big reason for me to never use it. - Jonathan M Davis
Re: DUB 0.9.20
El 29/11/13 21:54, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 20:17:54 UTC, Jordi Sayol wrote: El 29/11/13 20:37, ilya-stromberg ha escrit: On Friday, 29 November 2013 at 19:15:13 UTC, Jordi Sayol wrote: New dub v0.9.20 deb packages available at: d-apt http://d-apt.sourceforge.net/ Thank you. BTW, it would be great to have packages for previous DMD versions. You already support it for `libphobos2-nn` and almost for all other packages. libphobos2-nn and other packages ending with -nn contains the shared library necessary to run programs linked against them, so for this reason these packages have version on its name, allowing to install multiple versions of the same library. OK, I see. Can we have different DMD packages with different DMD names? For example, can we have `dmd-63` and `dmd-64` at the same time? So, the `dmd` is simple alias to the latest DMD version. Sorry if I miss something, but it looks like possible solution. Is not the target of this repository. To have multiple dmd versions on your system, you can use the Jacob Carlborg project https://github.com/jacob-carlborg/dvm Yes, I know. But packages save some time. -- Jordi Sayol
Re: DUB 0.9.20
Am 29.11.2013 21:27, schrieb Shammah Chancellor: On 2013-11-29 17:01:53 +, Sönke Ludwig said: - Builds are now cached and only rebuilt when necessary for dub build and dub run. Doesn't seem to be working correctly for me. Won't rebuild after a build failure. Hm... there may be an issue when the linker fails, but leaves a partially linked binary. I'll add some manual code that deletes the result after the linker returns with an error.
Re: DUB 0.9.20
Am 29.11.2013 23:05, schrieb Jonathan M Davis: On Friday, November 29, 2013 18:01:53 Sönke Ludwig wrote: - Running dub --build=ddox runs a local HTTP server that provides the docs instead of generating them all as actual HTML files. Why would that be desirable? I would expect a set of HTML files if generating documentation, and if a server is required to read the documentation instead of just bringing them up in your browser, that's a major usability problem IMHO. If ddox requires a server rather than just working with .html files, that would be a big reason for me to never use it. - Jonathan M Davis You can still use dub build --build=ddox to generate actual HTML files, but using run it will simply skip the generation part and displays the documentation much faster, depending on the size of the project.
Re: DUB 0.9.20
Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Thanks! Have you considered adding a version number to dub help and/or a --version option?
Re: DUB 0.9.20
El 30/11/13 02:08, Piotr Szturmaj ha escrit: Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Thanks! Have you considered adding a version number to dub help and/or a --version option? $ dub help prints version on last line: DUB version v0.9.20 -- Jordi Sayol
Re: DUB 0.9.20
On Saturday, 30 November 2013 at 02:16:50 UTC, Puming wrote: 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. When I build a vibe project, and edit the app.d and then build again, an error occurs: - Checking dependencies in '/media/sf_github/dsp' Error: Orphan format specifier: %File '%s' was modified in the future. Please re-save. - Sorry, this seems to be caused by a time problem in my share folder. please ignore it. But after I do a `ls` command (or other commands) and then `dub` again, it went ok again. Another thing to note is when app.d is modified, dub recompiles all the *.dt files, is that the case? Does dub support increment compiling?
Re: DUB 0.9.20
Am 30.11.2013 03:21, schrieb Puming: On Saturday, 30 November 2013 at 02:16:50 UTC, Puming wrote: 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. When I build a vibe project, and edit the app.d and then build again, an error occurs: - Checking dependencies in '/media/sf_github/dsp' Error: Orphan format specifier: %File '%s' was modified in the future. Please re-save. - Sorry, this seems to be caused by a time problem in my share folder. please ignore it. I've fixed the log message though, so it should read now just File '...' was modified in the future. Please re-save. But after I do a `ls` command (or other commands) and then `dub` again, it went ok again. Another thing to note is when app.d is modified, dub recompiles all the *.dt files, is that the case? Does dub support increment compiling? This is planned, but (AFAIK) this is not yet possible in an optimal way due to how DMD emits symbols to object files. Currently the only reliable way to build incrementally is to compile a single file at a time, but this is very inefficient compared to compiling multiple files in one go. A middle ground, which will be added in one of the next versions, is to build and cache each dependency as a separate static library. But this will still always build each complete package in one go, so all templates as well.
Re: DUB 0.9.20
On 2013-11-29 22:39:33 +, Sönke Ludwig said: Am 29.11.2013 21:27, schrieb Shammah Chancellor: On 2013-11-29 17:01:53 +, Sönke Ludwig said: - Builds are now cached and only rebuilt when necessary for dub build and dub run. Doesn't seem to be working correctly for me. Won't rebuild after a build failure. Hm... there may be an issue when the linker fails, but leaves a partially linked binary. I'll add some manual code that deletes the result after the linker returns with an error. I'll post an issue when I can isolate why it was doing it. I can't seem to reproduce it now, but it was definitely doing it earlier.It kept rerunning old binaries on me untill I made superfulous changes to files and re-saved.
Re: DUB 0.9.20
On 2013-11-30 02:58:50 +, Sönke Ludwig said: This is planned, but (AFAIK) this is not yet possible in an optimal way due to how DMD emits symbols to object files. Currently the only reliable way to build incrementally is to compile a single file at a time, but this is very inefficient compared to compiling multiple files in one go. Can you even do this when templated symbols are defined in that file? This was horribly broken years ago as the templated symbols were emitted into the source file that the template was in, rather than the including file.
