On 2/9/2013 9:04 PM, Leandro Lucarella wrote:
> No, is definitely the other way around. That's why you have a version control system. But never mind, I just want a binary with full version information for development snapshots. Is there any way to convince you to accept having that? Something needs to be changed, a way to differentiate releases from development snapshots. 

One simple way is just add a .h file with the info you want in it.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el  9 de February a las 21:17 me escribiste:
> On 2/9/2013 9:04 PM, Leandro Lucarella wrote:
> >No, is definitely the other way around. That's why you have a version control system. But never mind, I just want a binary with full version information for development snapshots. Is there any way to convince you to accept having that? Something needs to be changed, a way to differentiate releases from development snapshots.
> 
> One simple way is just add a .h file with the info you want in it.

I'm about to give up, but here is my last try.

I know how to implement this, there's even no need to add any .h file, that just makes things more complex without any advantage (at least for posix.mak), just a -DVERSION=\"-devel-`git whatever`\" and then changing the code to something like:

version =
#include "verstr.h" // or whatever the name is
VERSION;

That git whatever command just print the current HEAD short hash.

But then, if I do this, a way to flag that this is not a development snapshot needs to be added. This is also easy (again, at least in posix.mak), one way should be just adding the -DVERSION= stuff only if a Make RELEASE variable is equals to one. So, just 'make' will create a version string like v2.062-devel-cacafea, but make RELEASE=1 will create a aversion number with just v2.062.

I already have this in my private fork (not the RELEASE flag because
I never do releases :), I just want it upstream because is always better
to have the changes upstream and, especially, because I think this is
useful in the general case, so I want to contribute it back.

So, basically the question only for you is if changing your release scripts or whatever you use to add this RELEASE=1 would be too much work or if you're willing to do it and for everybody else too, if anybody is against this for any particular reason.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Every 5 minutes an area of rainforest the size of a foot ball field
Is eliminated
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 2/10/2013 10:19 AM, Leandro Lucarella wrote:
> Walter Bright, el  9 de February a las 21:17 me escribiste:
>> On 2/9/2013 9:04 PM, Leandro Lucarella wrote:
>>> No, is definitely the other way around. That's why you have a
>>> version control system. But never mind, I just want a binary with
>>> full version information for development snapshots. Is there any
>>> way to convince you to accept having that? Something needs to be
>>> changed, a way to differentiate releases from development
>>> snapshots.
>> One simple way is just add a .h file with the info you want in it.
> I'm about to give up, but here is my last try.
>
> I know how to implement this, there's even no need to add any .h file,
> that just makes things more complex without any advantage (at least for
> posix.mak), just a -DVERSION=\"-devel-`git whatever`\" and then changing
> the code to something like:
>
> version =
> #include "verstr.h" // or whatever the name is
> VERSION;
>
> That git whatever command just print the current HEAD short hash.
>
> But then, if I do this, a way to flag that this is not a development
> snapshot needs to be added. This is also easy (again, at least in
> posix.mak), one way should be just adding the -DVERSION= stuff only if
> a Make RELEASE variable is equals to one. So, just 'make' will create
> a version string like v2.062-devel-cacafea, but make RELEASE=1 will
> create a aversion number with just v2.062.
>
> I already have this in my private fork (not the RELEASE flag because
> I never do releases :), I just want it upstream because is always better
> to have the changes upstream and, especially, because I think this is
> useful in the general case, so I want to contribute it back.
>
> So, basically the question only for you is if changing your release
> scripts or whatever you use to add this RELEASE=1 would be too much work
> or if you're willing to do it and for everybody else too, if anybody is
> against this for any particular reason.


A problem with your approach is it won't work on Windows. The Windows command line is fairly limited. We got the VERSION thing to work under Windows, but the

-DVERSION=\"-devel-`git whatever`\"

would require additional tooling.

-DVERSION=\"-devel-`git whatever`\"

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 2/10/2013 10:19 AM, Leandro Lucarella wrote:
>  I just want it upstream because is always better to have the changes upstream and, especially, because I think this is useful in the general case, so I want to contribute it back.

I don't see a problem with doing a pull request for this, and seeing what others think rather than just me.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el 10 de February a las 11:44 me escribiste:
> 
> On 2/10/2013 10:19 AM, Leandro Lucarella wrote:
> > I just want it upstream because is always better to have the
> >changes upstream and, especially, because I think this is useful in the general case, so I want to contribute it back.
> 
> I don't see a problem with doing a pull request for this, and seeing what others think rather than just me.

I'm asking everybody here, is just that you are the only one replying. :)

And I'm asking before doing the pull request because there are several ways of doing this and I don't like doing pull requests that ends up in /dev/null, so before doing the pull request I thought it was better to ask (ok, I didn't expected to get so complicated, at this point it probably would have take less time to just do the pull request).

But also I asked here because I wanted to know if anybody knows an easy way to do this in Windows, because I don't and don't have a Windows environment in which I can try things out.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ingeniero Juanjo Charlante, Linux es como una mermelada?
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals