Le 2011-05-29 ? 19:39, Jonathan M Davis a ?crit :

> On 2011-05-29 16:33, Michel Fortin wrote:
>> I think the root of the problem is that it's not easy to setup things so that DMD, druntime, Phobos, and DMD's test suite are compiled together.
>> 
>> For my own use, I made an Xcode project that does all that (with some scripting that invokes the makefiles), but it took me some time to setup things. Perhaps what we need is a repository which would contain all those repositories (linked as submodules) along with the necessary code to make everything build. That way you can just clone that integration repository and compile everything in one go (and run all the tests) with no hassle. Perhaps I should create one...
> 
> I don't think that git can have sub-repositories like that. Certainly, git-svn can't deal with repositories that an svn repository references. You have to pull them all in individually and manage each of them individually. So, I don't think that having a repository which holds the others is going to work unless it's literally copying the code from the other repositories. It can't link them in.

<http://book.git-scm.com/5_submodules.html>

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On 2011-05-29 18:36, Michel Fortin wrote:
> Le 2011-05-29 ? 19:39, Jonathan M Davis a ?crit :
> > On 2011-05-29 16:33, Michel Fortin wrote:
> >> I think the root of the problem is that it's not easy to setup things so that DMD, druntime, Phobos, and DMD's test suite are compiled together.
> >> 
> >> For my own use, I made an Xcode project that does all that (with some scripting that invokes the makefiles), but it took me some time to setup things. Perhaps what we need is a repository which would contain all those repositories (linked as submodules) along with the necessary code to make everything build. That way you can just clone that integration repository and compile everything in one go (and run all the tests) with no hassle. Perhaps I should create one...
> > 
> > I don't think that git can have sub-repositories like that. Certainly, git-svn can't deal with repositories that an svn repository references. You have to pull them all in individually and manage each of them individually. So, I don't think that having a repository which holds the others is going to work unless it's literally copying the code from the other repositories. It can't link them in.
> 
> <http://book.git-scm.com/5_submodules.html>

Well, then I have no idea why git-svn doesn't use that to deal with external references in svn. It would make dealing with svn repositories much more pleasant is cases where svn repositories link in other repositories. Thanks for the info.

- Jonathan M Davis

On 5/29/2011 1:53 PM, Robert Clipsham wrote:
>
> I advise you add a README.md to the root of the dmd repository with contents looking something like:
> ----
> # DigitalMars D Compiler and Test Suite
>
> Compiler and test suite for the D programming language - http://d-programming-language.org/
>
> ## Building
>
> Replace $OS with windows, linux, osx, freebsd, solaris or openbsd depending on your operating system.
>
>     cd src
>     make -f $OS.mak
>
> ## Pull Requests
>
> When creating pull requests, please make sure to run the test suite before! Even if it's a small change and you think it's not needed - you'd be surprised what a small change can break!
>
> ## Running the test suite
>
> I actually don't know how to do this, but some instructions should go here. Also take a look at http://github.github.com/github-flavored-markdown/ for information on formatting in this file.
> ----
>
> I could clean this up and make a pull request if you're interested? ;)
>

Sure!

I think we should create a "Contribute" page on the Digitalmars site and the d-programming-language.org site.

On 29 May, 2011,at 10:53 PM, Robert Clipsham <robert at octarineparrot.com> wrote:

On 29 May 2011 19:13, Walter Bright <walter at digitalmars.com> wrote: For those doing compiler patches, I know it's a tough job, and thanks!

But please consider running the dmd test suite (and try to build/run phobos unittests) before issuing a pull request. There are a lot of interdependencies in the compiler, and the test suite is designed to flush them out. The cool thing is the test suite consists of cases that are already minimized! The suite also is designed to not take that long to run.

I run it constantly when I do dev on the compiler, and I constantly get dinged by it for something I overlooked. I consider the D test suite to be a major asset for us.

Please use it. If you've got problems using it, please post here and we'll try to help.

I advise you add a README.md to the root of the dmd repository with contents looking something like:
----
# DigitalMars D Compiler and Test Suite

Compiler and test suite for the D programming language - http://d-programming-language.org/

## Building

Replace $OS with windows, linux, osx, freebsd, solaris or openbsd depending on your operating system.

? ? cd src
? ? make -f $OS.mak

## Pull Requests

When creating pull requests, please make sure to run the test suite before! Even if it's a small change and you think it's not needed - you'd be surprised what a small change can break!

## Running the test suite

I actually don't know how to do this, but some instructions should go here. Also take a look at?http://github.github.com/github-flavored-markdown/ for information on formatting in this file.
----

I could clean this up and make a pull request if you're interested? ;)?

-- 
Robert
http://octarineparrot.com/
_______________________________________________
dmd-internals mailing list
dmd-internals at puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110530/32757e01/attachment.html>

On 30 May 2011 09:21, Walter Bright <walter at digitalmars.com> wrote:

>  On 5/29/2011 1:53 PM, Robert Clipsham wrote:
>
>>
>> .....
>>
>> ## Running the test suite
>>
>> I actually don't know how to do this, but some instructions should go here. Also take a look at http://github.github.com/github-flavored-markdown/ for information on formatting in this file.
>> ----
>>
>> I could clean this up and make a pull request if you're interested? ;)
>>
>>
> Sure!


I've just spent the past 10 minutes trying to figure out how to run the test suite so I can add instructions/make a pull request and can't manage it... It's no wonder it's not getting run!

I can get a range of different errors, I can't seem to manage to get dmd.conf set up correctly to remove all errors though. Perhaps it would be a good idea to include the relevant dmd.conf in the tests/ directory?

-- 
Robert
http://octarineparrot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110530/c4ae4d51/attachment.html>

On 5/30/2011 12:56 PM, Robert Clipsham wrote:
> On 30 May 2011 09:21, Walter Bright <walter at digitalmars.com <mailto:walter at digitalmars.com>> wrote:
> 
>     On 5/29/2011 1:53 PM, Robert Clipsham wrote:
> 
> 
>         .....
> 
>         ## Running the test suite
> 
>         I actually don't know how to do this, but some instructions should go here. Also take a look at
>         http://github.github.com/github-flavored-markdown/ for information on formatting in this file.
>         ----
> 
>         I could clean this up and make a pull request if you're interested? ;)
> 
> 
>     Sure!
> 
> 
> I've just spent the past 10 minutes trying to figure out how to run the test suite so I can add instructions/make a pull request and can't manage it... It's no wonder it's not getting run!
> 
> I can get a range of different errors, I can't seem to manage to get dmd.conf set up correctly to remove all errors
> though. Perhaps it would be a good idea to include the relevant dmd.conf in the tests/ directory?
> 

Lemee make this simple.. here's a simple makefile and dmd.conf file that 'just work'.

The make file are more complicated than the minimal necessary because they have a bunch of targets that I use while developing from time to time.  The default target, however, is enough to clone, build, and test all three packages.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110530/2a594e66/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmd.conf
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110530/2a594e66/attachment-0001.ksh>

Le 2011-05-30 ? 17:37, Brad Roberts a ?crit :

> Lemee make this simple.. here's a simple makefile and dmd.conf file that 'just work'.
> 
> The make file are more complicated than the minimal necessary because they have a bunch of targets that I use while developing from time to time.  The default target, however, is enough to clone, build, and test all three packages.
> 
> <Makefile.txt><dmd.conf>

Nice. How about creating a folder with these two files and then doing:

	git init
	git add Makefile.txt dmd.conf
	git submodule add https://github.com/D-Programming-Language/dmd.git dmd
	git submodule add https://github.com/D-Programming-Language/druntime.git druntime
	git submodule add https://github.com/D-Programming-Language/phobos.git phobos
	git commit -m "First integrated build system"

Then uploading this to github?

Next time someone wants a full build system he just does:

	git clone <url-to-repo>
	cd <repo-dir>
	git submodule update --init

and he has a full build system with the most recent commits in each repo. Later, if for some reason the build system need to change, sharing those changes is just a matter of pushing them for you and pulling them for others.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

I still have absolutely no idea why you've set up the tester in such a
complicated way with all these hard-coded paths -- and it doesn't
actually work if you also develop the D1 compiler.
If you simply copy the build result (dmd.exe, or phobos.lib) into the
correct place in your dmd directory, you can just run 'dmd', no need
to mess with all this nonsense about putting your dmd.conf into the
git directory, which does not work if you also test  D1.  In fact,
sticking *anything* in any of the git directories won't work.
Doing it the way you've done it, is pretty useless for anything except
running the test suite.


2011/5/30 Brad Roberts <braddr at puremagic.com>:
> On 5/30/2011 12:56 PM, Robert Clipsham wrote:
>> On 30 May 2011 09:21, Walter Bright <walter at digitalmars.com <mailto:walter at digitalmars.com>> wrote:
>>
>> ? ? On 5/29/2011 1:53 PM, Robert Clipsham wrote:
>>
>>
>> ? ? ? ? .....
>>
>> ? ? ? ? ## Running the test suite
>>
>> ? ? ? ? I actually don't know how to do this, but some instructions should go here. Also take a look at ? ? ? ? http://github.github.com/github-flavored-markdown/ for information on formatting in this file. ? ? ? ? ----
>>
>> ? ? ? ? I could clean this up and make a pull request if you're interested? ;)
>>
>>
>> ? ? Sure!
>>
>>
>> I've just spent the past 10 minutes trying to figure out how to run the test suite so I can add instructions/make a pull request and can't manage it... It's no wonder it's not getting run!
>>
>> I can get a range of different errors, I can't seem to manage to get dmd.conf set up correctly to remove all errors though. Perhaps it would be a good idea to include the relevant dmd.conf in the tests/ directory?
>>
>
> Lemee make this simple.. here's a simple makefile and dmd.conf file that 'just work'.
>
> The make file are more complicated than the minimal necessary because they have a bunch of targets that I use while developing from time to time. ?The default target, however, is enough to clone, build, and test all three packages.
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

While I haven't developed d1 in ages, it's roughly how I experimented with it back in the day.  I actually don't understand why you hate it so much or where you see complication.  What's "the correct place" mean to you?  It's all a matter of the dmd.conf file, which is easy to setup to match any configuration.

Shrug.  I'm a huge fan of test in place _then_ install.  But do whatever works for you.  I'm not trying to impose anything on anyone, just showing how I do it and how easy it is.

On 5/30/2011 5:53 PM, Don Clugston wrote:
> I still have absolutely no idea why you've set up the tester in such a
> complicated way with all these hard-coded paths -- and it doesn't
> actually work if you also develop the D1 compiler.
> If you simply copy the build result (dmd.exe, or phobos.lib) into the
> correct place in your dmd directory, you can just run 'dmd', no need
> to mess with all this nonsense about putting your dmd.conf into the
> git directory, which does not work if you also test  D1.  In fact,
> sticking *anything* in any of the git directories won't work.
> Doing it the way you've done it, is pretty useless for anything except
> running the test suite.
> 
> 
> 2011/5/30 Brad Roberts <braddr at puremagic.com>:
>> On 5/30/2011 12:56 PM, Robert Clipsham wrote:
>>> On 30 May 2011 09:21, Walter Bright <walter at digitalmars.com <mailto:walter at digitalmars.com>> wrote:
>>>
>>>     On 5/29/2011 1:53 PM, Robert Clipsham wrote:
>>>
>>>
>>>         .....
>>>
>>>         ## Running the test suite
>>>
>>>         I actually don't know how to do this, but some instructions should go here. Also take a look at
>>>         http://github.github.com/github-flavored-markdown/ for information on formatting in this file.
>>>         ----
>>>
>>>         I could clean this up and make a pull request if you're interested? ;)
>>>
>>>
>>>     Sure!
>>>
>>>
>>> I've just spent the past 10 minutes trying to figure out how to run the test suite so I can add instructions/make a pull request and can't manage it... It's no wonder it's not getting run!
>>>
>>> I can get a range of different errors, I can't seem to manage to get dmd.conf set up correctly to remove all errors though. Perhaps it would be a good idea to include the relevant dmd.conf in the tests/ directory?
>>>
>>
>> Lemee make this simple.. here's a simple makefile and dmd.conf file that 'just work'.
>>
>> The make file are more complicated than the minimal necessary because they have a bunch of targets that I use while developing from time to time.  The default target, however, is enough to clone, build, and test all three packages.
>>
>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 05/29/2011 04:19 PM, Brad Roberts wrote:
> On 5/29/2011 4:07 PM, Robert Clipsham wrote:
>> On 29 May 2011 19:13, Walter Bright<walter at digitalmars.com<mailto:walter at digitalmars.com>>  wrote:
>>
>>      For those doing compiler patches, I know it's a tough job, and thanks!
>>
>>      But please consider running the dmd test suite (and try to build/run phobos unittests) before issuing a pull
>>      request. There are a lot of interdependencies in the compiler, and the test suite is designed to flush them out. The
>>      cool thing is the test suite consists of cases that are already minimized! The suite also is designed to not take
>>      that long to run.
>>
>>      I run it constantly when I do dev on the compiler, and I constantly get dinged by it for something I overlooked. I
>>      consider the D test suite to be a major asset for us.
>>
>>      Please use it. If you've got problems using it, please post here and we'll try to help.
>>
>>
>> An idea relayed from Vladimir Panteleev: It could be a good idea to integrate pull requests with the automatic test runner - github has APIs for pull requests, the test runner could pull out the commits, test them, then post a comment on the pull request.
>>
>> I see a few problems with this however:
>>   - Added load for the test runner (although, they could be run with low priority and only when there aren't commits to
>> master to test)
>>   - Security - if you're testing all pull requests some sort of sandbox would be needed so the patch isn't running rm -rf
>> or something more malicious
>>   - More commits can be added to pull requests later on, it would need re-running in this case
>>   - The test suite could be altered to make it look like the pull request is fine - although I guess anything that gets
>> integrated will be looked over anyway, so this isn't much of an issue.
>>
>> -- 
>> Robert
>> http://octarineparrot.com/
> All of that could be dealt with, probably, but it still doesn't fix the underlying issue: developers should be running the tests on the code they ask to be pulled themselves, BEFORE the pull request is filed.  Not doing so puts potentially buggy code in the face of others to soon.
>
> Automated testing could help with finding conflicts between pull requests or something ahead of it being merged.  But using it as a crutch to not test yourself isn't something I want to encourage.

Why would it need to get even as a far as a pull request? Couldn't the auto-tester be set-up to test anything that can be pulled? If nothing else, it would allow people to test on *all* platforms before they file the request.