November 29, 2012
On 11/29/2012 11:50 AM, H. S. Teoh wrote:
> Rarely known fact: you can invoke make like this:
>
> 	make -f posix.mak MODEL=64
>
> There is no need to change the environment.
>
> (I don't know about Windows make, but I suspect something similar, if
> not the same, is possible.)

Not only is it similar, it's exactly the same.

November 29, 2012
On Thu, Nov 29, 2012 at 01:11:32PM +1100, Walter Bright wrote:
> On 11/29/2012 11:50 AM, H. S. Teoh wrote:
> >Rarely known fact: you can invoke make like this:
> >
> >	make -f posix.mak MODEL=64
> >
> >There is no need to change the environment.
> >
> >(I don't know about Windows make, but I suspect something similar, if
> >not the same, is possible.)
> 
> Not only is it similar, it's exactly the same.
[...]

Ah, so it isn't a GNU make thing. I tend to run into those every now and then.


T

-- 
Two American lawyers went down to the beach for a swim. Seeing a canoe rental nearby, one asked the other, "Roe, or Wade?"
November 29, 2012
On Thu, Nov 29, 2012 at 02:49:43AM +0100, deadalnix wrote:
> On Thursday, 29 November 2012 at 01:30:42 UTC, H. S. Teoh wrote:
> >Huh? Who said anything about master being stable? Obviously master is unstable by definition, since that's where the development work is being done. The whole point was to introduce a stable branch where we only pull in non-breaking changes from master.
> >
> 
> unstable != dev

OK, but dev implies unstable.


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and those who can't.
November 29, 2012
On 2012-11-28 23:26, Walter Bright wrote:

> If someone wants to be the champion of a stable D2 version branch, that
> would be great. His job would be to regularly review changes to D2,
> merge in the ones that make sense for the stable branch, make sure it
> gets through its test suite, and prepare releases of it now and then.

You also need to promise that you will put up the releases at dlang.org and pointing users to the stable release first and foremost.

-- 
/Jacob Carlborg
November 29, 2012
On 2012-11-29 01:50, Walter Bright wrote:

> Something has to be the default, and that dates back to when D was only
> implemented on 32 bit targets.

How about defaulting to the architecture one is building on?

-- 
/Jacob Carlborg
November 29, 2012
On 2012-11-28 22:40, 1100110 wrote:

> Would you be interested in helping?

Yes, but as I said, unfortunately I don't have the time. I also don't think I have enough knowledge about the compiler to do that. Sure I can always learn but I think I can put my time to better use in other D related projects, like I already do.

-- 
/Jacob Carlborg
November 29, 2012
On Thursday, November 29, 2012 08:45:53 Jacob Carlborg wrote:
> On 2012-11-29 01:50, Walter Bright wrote:
> > Something has to be the default, and that dates back to when D was only implemented on 32 bit targets.
> 
> How about defaulting to the architecture one is building on?

I believe that that's what most applications do when you build them - at least in *nix land. There, it really doesn't make sense to assume either 32-bit or 64-bit.

- Jonathan M Davis
November 29, 2012
On 2012-11-29 02:08, H. S. Teoh wrote:

> I think ultimately, as Walter has said, nothing is going to change
> unless somebody steps up to the plate and champions the effort to make a
> stable branch. Writing up proposals, specs, and other docs are good in
> theory, but won't accomplish a thing if nobody actually *does* anything
> about it. I think 1100110 has stepped up to make a stable branch; let's
> work with him to make it actually happen.

I don't think that is enough. We need to get some assurance that if someone creates a stable branch/fork there should be releases based on this branch on dlang.org and the site should be pointing users to the stable version first and foremost.

-- 
/Jacob Carlborg
November 29, 2012
On 28 November 2012 23:10, 1100110 <0b1100110@gmail.com> wrote:

> On 11/28/2012 02:48 PM, Iain Buclaw wrote:
>
>> On 28 November 2012 20:15, Jacob Carlborg<doob@me.com>  wrote:
>>
>>> On 2012-11-28 20:54, 1100110 wrote:
>>>
>>>
>>>  Soo....  Theoretically Speaking.
>>>>
>>>> If I were to create an Organization on Github for the management of stable D versions, would you work on it?
>>>>
>>>
>>>
>>> Yes, theoretically speaking. Unfortunately I don't have the time to do that.
>>>
>>> --
>>> /Jacob Carlborg
>>>
>>
>> So the plans of a stable releases branch never came into fruition?
>>
>>  https://github.com/D-**Programming-Language-Stable/**dmd<https://github.com/D-Programming-Language-Stable/dmd>
>
> Phobos and druntime are also in there.
>
> Right now I'm just trying to figure out how to organize it.
>

Perhaps this is a really stupid question...

But what's wrong with using branches in the main DMD repo?


November 29, 2012
On 29 November 2012 03:48, deadalnix <deadalnix@gmail.com> wrote:

> On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M Davis wrote:
>
>> Since master will almost certainly be the development branch, I don't see how
>>
>> that's a problem. The stable branch will be a separate branch, and
>> whoever is
>> managing the stable branch will merge stuff from the master branch into
>> it.
>>
>>
> In this case, all bug fixes are mixed with new feature and then have to be separated afterward and remerged into the stable branch. This is useless work and it is likely to cause merge conflict in the stable branch.
>
> Additionnaly, this become to really suck when several new features are dev at the same time.
>
> Finally, yhis is completely inconsistent with how github work in the first place.
>
> master make sense as an unstable branch, a release candidate, a beta or whatever, but certainly not a dev branch.


Why don't you document precisely what branches you think should exist, and
the working merge/rebase policies.
I'm actually very curious to know.


 Granted, major stuff like 64-bit Windows support and UDAs should probably
>> be
>> introduced on branches separate from master, and it's still a problem if
>> they're not, but it won't affect the stable branch if they're not.
>>
>>
> It will become all bigfixes will be based on code that contains the new feature.
>