Re: DUB 0.9.21 beta 1
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. In particular, I'm trying to give tested a try as it seems quite nice and I was looking for an automated way to generate computer-readable test results (results.json in this case). According to the github page for tested, with the latest version of dub (I'm using the beta version in OSX) I should just be able to add tested as a dependency and run dub test to generate test results. I created a package called dubtest, and set app.d to contain just a unittest with @name set from tested. I then run dub test, and get: Got library for false Checking dependencies in '/Users/kapps/dev/src/dubtest' Running unit tests for package dubtest, configuration 'library'. Package dubtest (configuration library) defines no main source file, this may cause certain build modes to fail. Add an explicit mainSourceFile to the package description to fix this. Error executing command test: Main source file not found in any import path. I also tried giving my app.d a void main() which has the same result. I also tried dub test dubtest --main-file=main.d where main.d just contains a void main and writeln, but this has the same result as well. If I specifically set targetType to executable in package.json and run dub test, then I get: Got for false Building package dubtest in /Users/kapps/dev/src/dubtest Got for false Checking dependencies in '/Users/kapps/dev/src/dubtest' Running unit tests for package dubtest, configuration ''. Error executing command test: Could not resolve configuration for package tested If I use dub --build=unittest however while it's set to executable, it will successfully build and reach my main (or give a linker error if no main is present / targetType is not executable). Overall, I can't seem to get dub test to work at all regardless of configuration. Ideally I'm looking for a way to have tested run my unittests and output a results.json without manually creating a main file since these projects are generally libraries and I'm trying to automate the process for continuous integration purposes.
Build Master: Progress toward 2.065
All, The following lists my progress and few points for which I need clarification. I created a git hub account (AndrewEdwards) and obtained necessary access to all repos at github.com/D-Programming-Language. Access to the ftp is pending but should be granted shortly. I've forked the following repos in order to comply with the Development_and_Release_Process documentation at wiki.dlang.org and Nick Sabalausky packaging tool: dmd, druntime, phobos, tools, dlang.org, installer Following instructions at [1], I created a local repository prepared branch 2.065 in accordance with [2] for the forked repositories. I've prepared a build environment on Mac OS X 10.9 with five VirtualBox images as follows: 1) Mac OS X 10.9 2) FreeBSD 9.2 3) Windows 7 4) Fedora 19 5) Ubuntu 12.04 SSH was configured on all systems and keys were generated and uploaded to GitHub. I am experiencing a slight problem on Fedora though. After initial config, I was able to login remotely but now receive the error Connection refused. Can't remember changing anything to cause this but anything is possible so I won't discount it. Worst case scenario, I'll wipe and reinstall it (for the novice the road to professional can seem very long). Cygwin is installed on Windows 7 and SSHD properly configured. Martin Norwak and Nick Sabalausky are working on polishing up the build script. Once this is complete, I will generate the binaries for the betas and upload. Questions requiring clarification: 1) Do I need to create a local repository on each system on which I build or does the one local repository on the base system suffice? 2) What is the process to update a branch with all changes master? I will need to do this because a lot of changes have occurred since the 2.065 branches were created but the actual betas are not yet prepared. Going forward, this is the only time this will occur. 3) Walter: Need your input/decision on what which tools are strictly required for the dmd release. Note: Release 2.065 will be treated in the same fashion as previous releases in order to afford devs additional time to become familiar with documented release process. Meaning, after the betas are prepared and made available, bug fixes will merged to master and regressions cherry-picked into the branch. I'm aiming to make betas public by 17 December. Regards, Andrew - [1] http://wiki.dlang.org/Development_and_Release_Process#Local_repository_setup [2] http://wiki.dlang.org/Development_and_Release_Process#Preparing_a_new_major_release
Re: Fedora RPMs
On Thursday, 5 December 2013 at 11:46:37 UTC, Martin Nowak wrote: On 11/19/2013 02:11 AM, Dejan Lekic wrote: Hello everybody. I have just committed few changes to https://www.gitorious.org/dejan- fedora that allow you to build functional RPMs on your Fedora 19 systems. I will aim for now to support F19, F20, EL5 and EL6. If someone needs support for something else, please send patches or just simply come to IRC and let me know what is the problem. :) Great, will you take the honour to submit this to Fedora? Few remarks - SPEC file expects source files to be on http://ddn.so/ files/ . I hope our release manager, or so-called build master will make sure dlang.org provides source tarballs of dmd, phobos, druntime and tools the same or similar way I have them on http://ddn.so/files/ (btw, you can't browse it yet, but you can download files). I use the simple get-files.sh (located in the dmd directory in the dejan- fedora repo) to get those release tarballs from GitHub. Finally, I decided to be little bit adventurous and made the SPEC file generate dmd.conf with -defaultlib=libphobos2.so flag in DFLAGS. It would be better to stick to the current dlang state. Following Fedora package guidelines, I provide static library in the libphobos-static package instead. Splitting in different packages is needed to comply with RPM guidelines, but it's a bad fit for a single binary installer on dlang.org. I'm working on a spec file for the latter. https://github.com/dawgfoto/installer/tree/fedoraSPEC Btw, I forgot to tell you... I talked to fedora people about having dmd in Fedora. They said it will probably be rejected because of the backend license, because they are not allowed to freely distribute the software. So I guess we will most likely have to setup our own YUM repository on dlang.org - that is probably the best course of action. If someone has better idea, please share it.
Re: Build Master: Progress toward 2.065
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote: I am experiencing a slight problem on Fedora though. After initial config, I was able to login remotely but now receive the error Connection refused. Can't remember changing anything to cause this but anything is possible so I won't discount it. Maybe you have forgotten to add ssh daemon to autostart list?
Re: Build Master: Progress toward 2.065
On 2013-12-09 15:48, Andrew Edwards wrote: I've prepared a build environment on Mac OS X 10.9 with five VirtualBox images as follows: 1) Mac OS X 10.9 Make sure I got GCC, I don't think the test suite passes if DMD built with Clang. -- /Jacob Carlborg
Re: Build Master: Progress toward 2.065
Also I don't think you need to bother with maintaining own forks unless you are planning to actually push something upstream. Just cloning core repos on build systems should be enough.
Re: Build Master: Progress toward 2.065
On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote: 2) What is the process to update a branch with all changes master? I will need to do this because a lot of changes have occurred since the 2.065 branches were created but the actual betas are not yet prepared. Going forward, this is the only time this will occur. If branch does not have own commits to be preserved and needs to just be synced with master state (assuming D-Programming-Language remote is named `upstream`): git fetch upstream # download current remote state git checkout 2.065 # go to release branch git reset --hard upstream/master # make it identical to current master git push -f origin 2.065 # update own fork git push -f upstream 2.065 # update branch in core repos, careful here! I can't imagine any other case when one may want to update release branch from master so it must the what you need.
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.21 beta 1
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.
Re: Build Master: Progress toward 2.065
On 12/9/13, 10:28 AM, Dicebot wrote: On Monday, 9 December 2013 at 14:49:05 UTC, Andrew Edwards wrote: I am experiencing a slight problem on Fedora though. After initial config, I was able to login remotely but now receive the error Connection refused. Can't remember changing anything to cause this but anything is possible so I won't discount it. Maybe you have forgotten to add ssh daemon to autostart list? Thanks... that's exactly it.
Re: Build Master: Progress toward 2.065
On 12/9/13, 10:36 AM, Dicebot wrote: Also I don't think you need to bother with maintaining own forks unless you are planning to actually push something upstream. Just cloning core repos on build systems should be enough. At least for the time being, the only things I need to push are tags/branches when I create them. Hopefully that will change in the future.
Re: Build Master: Progress toward 2.065
On 2013-12-09 16:30, Jacob Carlborg wrote: Make sure I got GCC, I don't think the test suite passes if DMD built with Clang. * you got. -- /Jacob Carlborg
