Testing for compiler features or compiler (repo) version?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Testing for compiler features or compiler (repo) version?

Dion Whitehead Amago
I'm usually using the latest haxe compiler, fresh from the repository.
 There are too many useful features and fixes compared to the stable
version.

However this becomes tricky when I want to update a haxelib library.
Of course, the haxelib version should be compatible with the stable
compiler, but it starts getting complicated when you develop using one
version, but want to publish with another.

Specifically the @:overload feature.

The question: can the compiler know what *repo* version it is, or if a
feature is available?

At the moment I'm just using a custom -D compiler flag "haxedev".
Does anybody have a better/fancier solution?

Dion

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing for compiler features or compiler (repo) version?

Cauê W.
So, for the stable releases there is the -D haxe_20x compiler flag.

It's a little tricky, though, because it's not retroactive, so haxe_206 isn't set on haxe_207. I once had a large codebase just stop working because of this! :S

Anyway, there was some discussion some time ago with adding some kind of string identifier of what svn version the nightlies were compiled. It's quite easy to add this kind of behaviour on the build servers, so maybe if it's ok to run a quick 'n dirty find & replace on the main.ml as part of the nightly builds pipeline I could add this. What do you think. Nicolas?

2011/9/2 Dion Whitehead Amago <[hidden email]>
I'm usually using the latest haxe compiler, fresh from the repository.
 There are too many useful features and fixes compared to the stable
version.

However this becomes tricky when I want to update a haxelib library.
Of course, the haxelib version should be compatible with the stable
compiler, but it starts getting complicated when you develop using one
version, but want to publish with another.

Specifically the @:overload feature.

The question: can the compiler know what *repo* version it is, or if a
feature is available?

At the moment I'm just using a custom -D compiler flag "haxedev".
Does anybody have a better/fancier solution?

Dion

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing for compiler features or compiler (repo) version?

Nicolas Cannasse
Le 04/09/2011 00:34, Cauê Waneck a écrit :

> So, for the stable releases there is the -D haxe_20x compiler flag.
>
> It's a little tricky, though, because it's not retroactive, so haxe_206
> isn't set on haxe_207. I once had a large codebase just stop working
> because of this! :S
>
> Anyway, there was some discussion some time ago with adding some kind of
> string identifier of what svn version the nightlies were compiled. It's
> quite easy to add this kind of behaviour on the build servers, so maybe
> if it's ok to run a quick 'n dirty find & replace on the main.ml
> <http://main.ml> as part of the nightly builds pipeline I could add
> this. What do you think. Nicolas?

Go on if you wish ;)

You can tag 2.07-r1234 or something else.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing for compiler features or compiler (repo) version?

Cauê W.
what do you think about numbering them as 2.08 for example, so you can do
#if haxe_208
....
#else
....
#end

and hopefully don't need to change the code once the next version is out

2011/9/4 Nicolas Cannasse <[hidden email]>
Le 04/09/2011 00:34, Cauê Waneck a écrit :
So, for the stable releases there is the -D haxe_20x compiler flag.

It's a little tricky, though, because it's not retroactive, so haxe_206
isn't set on haxe_207. I once had a large codebase just stop working
because of this! :S

Anyway, there was some discussion some time ago with adding some kind of
string identifier of what svn version the nightlies were compiled. It's
quite easy to add this kind of behaviour on the build servers, so maybe
if it's ok to run a quick 'n dirty find & replace on the main.ml
<http://main.ml> as part of the nightly builds pipeline I could add

this. What do you think. Nicolas?

Go on if you wish ;)

You can tag 2.07-r1234 or something else.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing for compiler features or compiler (repo) version?

Nicolas Cannasse
Le 04/09/2011 15:22, Cauê Waneck a écrit :
> what do you think about numbering them as 2.08 for example, so you can do
> #if haxe_208
> ....
> #else
> ....
> #end
>
> and hopefully don't need to change the code once the next version is out

Yes that makes sense.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing for compiler features or compiler (repo) version?

Dion Whitehead Amago
Yes, that would work, as long as the repo version was a version above
the stable version, ie as soon as the stable version is released, all
subsequent versions that contain extra features (not just bugfixes)
are the new version.  So, that would mean the the version checked out
of the repo right now would be haxe_208, since the stable version is
haxe_207.

On Sun, Sep 4, 2011 at 11:43 AM, Nicolas Cannasse
<[hidden email]> wrote:

> Le 04/09/2011 15:22, Cauê Waneck a écrit :
>>
>> what do you think about numbering them as 2.08 for example, so you can do
>> #if haxe_208
>> ....
>> #else
>> ....
>> #end
>>
>> and hopefully don't need to change the code once the next version is out
>
> Yes that makes sense.
>
> Best,
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Testing for compiler features or compiler (repo) version?

Cauê W.
ok guys, it's done!

I'll pass the script to Bernard Visscher, which is the maintainer of the linux32 and osx10.6 builds!

The other ones are already working this way. The script will only look for the version definition, increment it by one, and then add the revision information to the compiler info

cheers!

2011/9/4 Dion Whitehead Amago <[hidden email]>
Yes, that would work, as long as the repo version was a version above
the stable version, ie as soon as the stable version is released, all
subsequent versions that contain extra features (not just bugfixes)
are the new version.  So, that would mean the the version checked out
of the repo right now would be haxe_208, since the stable version is
haxe_207.

On Sun, Sep 4, 2011 at 11:43 AM, Nicolas Cannasse
<[hidden email]> wrote:
> Le 04/09/2011 15:22, Cauê Waneck a écrit :
>>
>> what do you think about numbering them as 2.08 for example, so you can do
>> #if haxe_208
>> ....
>> #else
>> ....
>> #end
>>
>> and hopefully don't need to change the code once the next version is out
>
> Yes that makes sense.
>
> Best,
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org