On Wed, Nov 28, 2012 at 06:31:45PM -0600, 1100110 wrote: [...]
> Oh! while I have your attention...  Looking at the makefiles for DMD, all of them are set to build 32bit by default.  Usually that is unset, and the environment that you are compiling in dictates which one is implicitly chosen.
> 
> Why have it set to build 32 by default?  It's not an issue or anything, but it's been a long time since I've had a setup capable of build  32bit apps easily.  I always have to change that.  Is there any particular reason that that option is set rather than unset?

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.)


T

-- 
There is no gravity. The earth sucks.

On 11/29/2012 11:31 AM, 1100110 wrote:
> Why have it set to build 32 by default?  It's not an issue or anything,
> but it's been a long time since I've had a setup capable of build  32bit
> apps easily.  I always have to change that.  Is there any particular
> reason that that option is set rather than unset?

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

Anyhow, I usually use a custom makefile to drive the dmd makefiles, setting the various macros as appropriate for my setup, so the defaults are kinda irrelevant.

eskimo:

> Even the unstable branch should stop adding new features let's say at
> least three months before the next stable release, so all things in
> stable have been tested at least a certain minimum amount of time in
> unstable. (People can still work on new features, but only in separate
> feature branches, which will not be part of the next stable release.)

Maybe there are alternative ways to do this.

But generally I agree with your post and I suggest to make a little DEP out of it, or to copy your post somewhere in the Wiki, to make it the starting point (to be improved, where necessary) document for the future D development process.

Bye,
bearophile

On 11/28/2012 06:50 PM, H. S. Teoh wrote:
> On Wed, Nov 28, 2012 at 06:31:45PM -0600, 1100110 wrote:
> [...]
>> Oh! while I have your attention...  Looking at the makefiles for
>> DMD, all of them are set to build 32bit by default.  Usually that is
>> unset, and the environment that you are compiling in dictates which
>> one is implicitly chosen.
>>
>> Why have it set to build 32 by default?  It's not an issue or
>> anything, but it's been a long time since I've had a setup capable
>> of build  32bit apps easily.  I always have to change that.  Is
>> there any particular reason that that option is set rather than
>> unset?
>
> 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.)
>
>
> T
>

I know, I just have a bad habit of digging through makefiles and such before Ill run them.  When its literally right under the cursor its just easier to edit it.  I was really just curious why it wasn't left undefined.

It *seems* to be building fine without that option defined, and with the way Linux is going I simply cannot believe that I'm the only one for whom that messes up a default build.

On Thu, Nov 29, 2012 at 01:51:52AM +0100, bearophile wrote:
> eskimo:
> 
> >Even the unstable branch should stop adding new features let's say at least three months before the next stable release, so all things in stable have been tested at least a certain minimum amount of time in unstable. (People can still work on new features, but only in separate feature branches, which will not be part of the next stable release.)
> 
> Maybe there are alternative ways to do this.
> 
> But generally I agree with your post and I suggest to make a little DEP out of it, or to copy your post somewhere in the Wiki, to make it the starting point (to be improved, where necessary) document for the future D development process.
[...]

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.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly

On Thursday, 29 November 2012 at 01:06:15 UTC, 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'm sorry, but I don't see how a champion can prevent stuff to be dropped directly into master, unless going to some extreme and sequestrate people, which is illegal in most countries.

On Thursday, November 29, 2012 02:13:10 deadalnix wrote:
> On Thursday, 29 November 2012 at 01:06:15 UTC, 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'm sorry, but I don't see how a champion can prevent stuff to be dropped directly into master, unless going to some extreme and sequestrate people, which is illegal in most countries.

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.

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.

- Jonathan M Davis

On Thu, Nov 29, 2012 at 02:13:10AM +0100, deadalnix wrote:
> On Thursday, 29 November 2012 at 01:06:15 UTC, 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'm sorry, but I don't see how a champion can prevent stuff to be dropped directly into master, unless going to some extreme and sequestrate people, which is illegal in most countries.

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.


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall

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.

> 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.

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