Feature request: #defines

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

Feature request: #defines

Cauê W.
Hey Guys!

I've got a quick feature request:

It would be great if haXe supported #define 's . It would make some difference for writing maintainable compiler directives.

So e.g.

#if SomeDefine
#define OtherDefine
#end

This would be great for e.g.:

#if (php || neko || cpp)
#define HandlesFiles
#end


and then:
#if HandlesFiles
//code here with neko/php/cpp .io.File
#end

Of course the code with neko/php/cpp .io.File would still have to be converted with remaps, but it would be great to have this so we can have defines like AS3OriginalCode (for e.g.the unmodified haXe version of an AS3 library), or in the case of HandlesFiles for supporting more targets as they are added to haXe.

Thanks!
Cauê

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

Re: Feature request: #defines

Justin Donaldson-2
I thought this would be a good idea too, although it looks like we're defining the behavior differently:

http://lists.motion-twin.com/pipermail/haxe/2009-July/027526.html

The #define macro in C functions more like the example in the above link (inserting functions and variables at compile time).
http://www.cprogramming.com/reference/preprocessor/define.html

-Justin

On Thu, Jul 29, 2010 at 1:45 PM, Cauê Waneck <[hidden email]> wrote:
Hey Guys!

I've got a quick feature request:

It would be great if haXe supported #define 's . It would make some difference for writing maintainable compiler directives.

So e.g.

#if SomeDefine
#define OtherDefine
#end

This would be great for e.g.:

#if (php || neko || cpp)
#define HandlesFiles
#end


and then:
#if HandlesFiles
//code here with neko/php/cpp .io.File
#end

Of course the code with neko/php/cpp .io.File would still have to be converted with remaps, but it would be great to have this so we can have defines like AS3OriginalCode (for e.g.the unmodified haXe version of an AS3 library), or in the case of HandlesFiles for supporting more targets as they are added to haXe.

Thanks!
Cauê

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



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


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

Re: Feature request: #defines

MarcWeber
In reply to this post by Cauê W.
Does HaXe have a strict order in which it reads imports?
If not the same source code could result in different code.

import A; # A defines something B is using
import B; # if B is read first without the define found in A ..

Marc Weber

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

Re: Feature request: #defines

Justin Donaldson-2
Yes, optimally it should function like C++, which is basically a global find and replace mechanism for tokens.  The process starts when the #define is encountered in the build process.  So, import order could affect functionality if #defines are used.

#define is pretty dangerous to use in C++, and most "best practice" guidelines restrict its use:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#The__define_Guard

I think it's powerful if used appropriately... In my case, I was giving an example where a class was setting a macro to redefine one of its own static functions. There's a very minimal risk there for it to affect external code.  You could screw things up by typedefing the original class, or overloading the type with a typedef, or by "using" the class, but those are all pretty acceptable limitations, and in the worst case will cause immediately apparent errors that can be fixed.


Of course, a lot of what I'd like to do with #define should be possible with the haxe xml format:
http://haxe.org/com/features

modifying function calls in the xml, and then passing it back into the compiler should enable the same effect.  So, I'm planning on going that route.

-Justin


On Thu, Jul 29, 2010 at 2:49 PM, Marc Weber <[hidden email]> wrote:
Does HaXe have a strict order in which it reads imports?
If not the same source code could result in different code.

import A; # A defines something B is using
import B; # if B is read first without the define found in A ..

Marc Weber

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



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


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

Re: Feature request: #defines

Cauê W.
The order issue could be easily solved by placing all the defines in a special folder, possibly called defines, or something like that. So the build process for haXe would involve first visiting the defines folder in every class path defined.

2010/7/29 Justin Donaldson <[hidden email]>
Yes, optimally it should function like C++, which is basically a global find and replace mechanism for tokens.  The process starts when the #define is encountered in the build process.  So, import order could affect functionality if #defines are used.

#define is pretty dangerous to use in C++, and most "best practice" guidelines restrict its use:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#The__define_Guard

I think it's powerful if used appropriately... In my case, I was giving an example where a class was setting a macro to redefine one of its own static functions. There's a very minimal risk there for it to affect external code.  You could screw things up by typedefing the original class, or overloading the type with a typedef, or by "using" the class, but those are all pretty acceptable limitations, and in the worst case will cause immediately apparent errors that can be fixed.


Of course, a lot of what I'd like to do with #define should be possible with the haxe xml format:
http://haxe.org/com/features

modifying function calls in the xml, and then passing it back into the compiler should enable the same effect.  So, I'm planning on going that route.

-Justin



On Thu, Jul 29, 2010 at 2:49 PM, Marc Weber <[hidden email]> wrote:
Does HaXe have a strict order in which it reads imports?
If not the same source code could result in different code.

import A; # A defines something B is using
import B; # if B is read first without the define found in A ..

Marc Weber

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



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


--
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: Feature request: #defines

Justin Donaldson-2
Wouldn't the order of class path declarations matter as well then?  I think all of these details become the reason why people don't like #define :)

I linked the wrong section on that google style guide btw, I meant this:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Preprocessor_Macros



-Justin

On Thu, Jul 29, 2010 at 3:34 PM, Cauê Waneck <[hidden email]> wrote:
The order issue could be easily solved by placing all the defines in a special folder, possibly called defines, or something like that. So the build process for haXe would involve first visiting the defines folder in every class path defined.

2010/7/29 Justin Donaldson <[hidden email]>

Yes, optimally it should function like C++, which is basically a global find and replace mechanism for tokens.  The process starts when the #define is encountered in the build process.  So, import order could affect functionality if #defines are used.

#define is pretty dangerous to use in C++, and most "best practice" guidelines restrict its use:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#The__define_Guard

I think it's powerful if used appropriately... In my case, I was giving an example where a class was setting a macro to redefine one of its own static functions. There's a very minimal risk there for it to affect external code.  You could screw things up by typedefing the original class, or overloading the type with a typedef, or by "using" the class, but those are all pretty acceptable limitations, and in the worst case will cause immediately apparent errors that can be fixed.


Of course, a lot of what I'd like to do with #define should be possible with the haxe xml format:
http://haxe.org/com/features

modifying function calls in the xml, and then passing it back into the compiler should enable the same effect.  So, I'm planning on going that route.

-Justin



On Thu, Jul 29, 2010 at 2:49 PM, Marc Weber <[hidden email]> wrote:
Does HaXe have a strict order in which it reads imports?
If not the same source code could result in different code.

import A; # A defines something B is using
import B; # if B is read first without the define found in A ..

Marc Weber

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



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


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


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



--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


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

Re: Feature request: #defines

Nicolas Cannasse
In reply to this post by Cauê W.
Cauê Waneck a écrit :

> Hey Guys!
>
> I've got a quick feature request:
>
> It would be great if haXe supported #define 's . It would make some
> difference for writing maintainable compiler directives.
>
> So e.g.
>
> #if SomeDefine
> #define OtherDefine
> #end
>
> This would be great for e.g.:
>
> #if (php || neko || cpp)
> #define HandlesFiles
> #end

You can already use  -D HandleFiles  as part of the compiler parameters
when you're compiling for one of these three platforms.

Best,
Nicolas

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

Re: Feature request: #defines

Cauê W.
Hey Nicolas!

You can already use  -D HandleFiles  as part of the compiler parameters when you're compiling for one of these three platforms.

I know that! : )
THe problem is that if this is going to be in a library, we have to make sure everyone knows that, and doesn't forget, because it can generate some silent and hard-to-track errors. So for now, my code looks like this

#if (cpp || neko || php)

all over the place

It's worse for when you have some "nested levels" of compiler switches, like that:

AW_NO_MEMORY_API

and AW_ORIGINAL_AS3

if I could, I'd make:
#if AW_ORIGINAL_AS3
#define AW_NO_MEMORY_API
#end

and use it like that
#if (AW_NO_MEMORY_API)
...
#else
....
#end

but instead I have to do:

#if (AW_ORIGINAL_AS3 || AW_NO_MEMORY_API)
...
#else
...
#end

Oh well, it was only a suggestion. Would be nice to have it, though ! : )
 
Justin Donaldson
Wouldn't the order of class path declarations matter as well then?  I think all of these details become the reason why people don't like #define :)

 Justin, the order of class path declarations really could interfere with that, but I don't really think it would. It's like you say that a compiler directive CAN clash with another one, so that two libs use the same directive name for different purpouses. But in reality you just need to make it unique. If each library is taking care of its own compiler directives, the order of classpaths can only make a difference if you are trying to do something very.... dangerous. You know? Like defining yourself some defines for other libs, etc.

cheers
Caue

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

Re: Feature request: #defines

clemos
Hi Cauê

I think you could easily handle these kinds of things with a proper
build system like a Makefile, and compiler flags, or with a
preprocessor.
So, to me, it's not really worth adding this feature to the compiler
itself; the conditionnal compiling feature is enough, the haXe
compiler is not meant to include preprocessing features or a more
complex build system than mere .hxml files, in my opinion...

Clément

On Fri, Jul 30, 2010 at 1:47 PM, Cauê Waneck <[hidden email]> wrote:

> Hey Nicolas!
>>
>> You can already use  -D HandleFiles  as part of the compiler parameters
>> when you're compiling for one of these three platforms.
>
> I know that! : )
> THe problem is that if this is going to be in a library, we have to make
> sure everyone knows that, and doesn't forget, because it can generate some
> silent and hard-to-track errors. So for now, my code looks like this
>
>> #if (cpp || neko || php)
>
> all over the place
>
> It's worse for when you have some "nested levels" of compiler switches, like
> that:
>
> AW_NO_MEMORY_API
>
> and AW_ORIGINAL_AS3
>
> if I could, I'd make:
> #if AW_ORIGINAL_AS3
> #define AW_NO_MEMORY_API
> #end
>
> and use it like that
>>
>> #if (AW_NO_MEMORY_API)
>> ...
>> #else
>> ....
>> #end
>
> but instead I have to do:
>
>> #if (AW_ORIGINAL_AS3 || AW_NO_MEMORY_API)
>> ...
>> #else
>> ...
>> #end
>
> Oh well, it was only a suggestion. Would be nice to have it, though ! : )
>
>>
>> Justin Donaldson
>>
>> Wouldn't the order of class path declarations matter as well then?  I
>> think all of these details become the reason why people don't like #define
>> :)
>
>  Justin, the order of class path declarations really could interfere with
> that, but I don't really think it would. It's like you say that a compiler
> directive CAN clash with another one, so that two libs use the same
> directive name for different purpouses. But in reality you just need to make
> it unique. If each library is taking care of its own compiler directives,
> the order of classpaths can only make a difference if you are trying to do
> something very.... dangerous. You know? Like defining yourself some defines
> for other libs, etc.
>
> cheers
> Caue
>
> --
> 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: Feature request: #defines

Cauê W.
clement, but what if you are making a library for use, and it should be the most user-friendly?

2010/7/30 clemos <[hidden email]>
Hi Cauê

I think you could easily handle these kinds of things with a proper
build system like a Makefile, and compiler flags, or with a
preprocessor.
So, to me, it's not really worth adding this feature to the compiler
itself; the conditionnal compiling feature is enough, the haXe
compiler is not meant to include preprocessing features or a more
complex build system than mere .hxml files, in my opinion...

Clément

On Fri, Jul 30, 2010 at 1:47 PM, Cauê Waneck <[hidden email]> wrote:
> Hey Nicolas!
>>
>> You can already use  -D HandleFiles  as part of the compiler parameters
>> when you're compiling for one of these three platforms.
>
> I know that! : )
> THe problem is that if this is going to be in a library, we have to make
> sure everyone knows that, and doesn't forget, because it can generate some
> silent and hard-to-track errors. So for now, my code looks like this
>
>> #if (cpp || neko || php)
>
> all over the place
>
> It's worse for when you have some "nested levels" of compiler switches, like
> that:
>
> AW_NO_MEMORY_API
>
> and AW_ORIGINAL_AS3
>
> if I could, I'd make:
> #if AW_ORIGINAL_AS3
> #define AW_NO_MEMORY_API
> #end
>
> and use it like that
>>
>> #if (AW_NO_MEMORY_API)
>> ...
>> #else
>> ....
>> #end
>
> but instead I have to do:
>
>> #if (AW_ORIGINAL_AS3 || AW_NO_MEMORY_API)
>> ...
>> #else
>> ...
>> #end
>
> Oh well, it was only a suggestion. Would be nice to have it, though ! : )
>
>>
>> Justin Donaldson
>>
>> Wouldn't the order of class path declarations matter as well then?  I
>> think all of these details become the reason why people don't like #define
>> :)
>
>  Justin, the order of class path declarations really could interfere with
> that, but I don't really think it would. It's like you say that a compiler
> directive CAN clash with another one, so that two libs use the same
> directive name for different purpouses. But in reality you just need to make
> it unique. If each library is taking care of its own compiler directives,
> the order of classpaths can only make a difference if you are trying to do
> something very.... dangerous. You know? Like defining yourself some defines
> for other libs, etc.
>
> cheers
> Caue
>
> --
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Feature request: #defines

clemos
Yes I see your point. This excludes using a Makefile, right ?
But it doesn't exclude the preprocessing solution: you could simply
put your flags exactly the way you would if you had this #define
feature,
when releasing the library,you could make a preprocessor expand "#if
AW_NO_MEMORY_API" to "#if (AW_ORIGINAL_AS3 || AW_NO_MEMORY_API)",
something like that...

On Fri, Jul 30, 2010 at 2:08 PM, Cauê Waneck <[hidden email]> wrote:

> clement, but what if you are making a library for use, and it should be the
> most user-friendly?
>
> 2010/7/30 clemos <[hidden email]>
>>
>> Hi Cauê
>>
>> I think you could easily handle these kinds of things with a proper
>> build system like a Makefile, and compiler flags, or with a
>> preprocessor.
>> So, to me, it's not really worth adding this feature to the compiler
>> itself; the conditionnal compiling feature is enough, the haXe
>> compiler is not meant to include preprocessing features or a more
>> complex build system than mere .hxml files, in my opinion...
>>
>> Clément
>>
>> On Fri, Jul 30, 2010 at 1:47 PM, Cauê Waneck <[hidden email]> wrote:
>> > Hey Nicolas!
>> >>
>> >> You can already use  -D HandleFiles  as part of the compiler parameters
>> >> when you're compiling for one of these three platforms.
>> >
>> > I know that! : )
>> > THe problem is that if this is going to be in a library, we have to make
>> > sure everyone knows that, and doesn't forget, because it can generate
>> > some
>> > silent and hard-to-track errors. So for now, my code looks like this
>> >
>> >> #if (cpp || neko || php)
>> >
>> > all over the place
>> >
>> > It's worse for when you have some "nested levels" of compiler switches,
>> > like
>> > that:
>> >
>> > AW_NO_MEMORY_API
>> >
>> > and AW_ORIGINAL_AS3
>> >
>> > if I could, I'd make:
>> > #if AW_ORIGINAL_AS3
>> > #define AW_NO_MEMORY_API
>> > #end
>> >
>> > and use it like that
>> >>
>> >> #if (AW_NO_MEMORY_API)
>> >> ...
>> >> #else
>> >> ....
>> >> #end
>> >
>> > but instead I have to do:
>> >
>> >> #if (AW_ORIGINAL_AS3 || AW_NO_MEMORY_API)
>> >> ...
>> >> #else
>> >> ...
>> >> #end
>> >
>> > Oh well, it was only a suggestion. Would be nice to have it, though ! :
>> > )
>> >
>> >>
>> >> Justin Donaldson
>> >>
>> >> Wouldn't the order of class path declarations matter as well then?  I
>> >> think all of these details become the reason why people don't like
>> >> #define
>> >> :)
>> >
>> >  Justin, the order of class path declarations really could interfere
>> > with
>> > that, but I don't really think it would. It's like you say that a
>> > compiler
>> > directive CAN clash with another one, so that two libs use the same
>> > directive name for different purpouses. But in reality you just need to
>> > make
>> > it unique. If each library is taking care of its own compiler
>> > directives,
>> > the order of classpaths can only make a difference if you are trying to
>> > do
>> > something very.... dangerous. You know? Like defining yourself some
>> > defines
>> > for other libs, etc.
>> >
>> > cheers
>> > Caue
>> >
>> > --
>> > 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
>

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

Re: Feature request: #defines

Nicolas Cannasse
In reply to this post by Cauê W.
Cauê Waneck a écrit :

> Hey Nicolas!
>
>
>     You can already use  -D HandleFiles  as part of the compiler
>     parameters when you're compiling for one of these three platforms.
>
>
> I know that! : )
> THe problem is that if this is going to be in a library, we have to make
> sure everyone knows that, and doesn't forget, because it can generate
> some silent and hard-to-track errors. So for now, my code looks like this

Yes, I can understand.
This is not best of usability, but you can still do the following :

#if !(HandleFiles || NotHandleFiles)
#error "Please specify either -D HandleFiles or -D NotHandleFiles"
#end

Nicolas


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

Re: Feature request: #defines

Cauê W.

This is not best of usability, but you can still do the following :

#if !(HandleFiles || NotHandleFiles)
#error "Please specify either -D HandleFiles or -D NotHandleFiles"
#end

Got it!!

Thanks for the tip, will use that!

By the way, what about that package remapping on the haXe to-do's? For the next release, if you want, I could make the conditional typedefs so you can use haxe.io.File instead of (neko || cpp || php).io.File , etc


Cheers! Thanks
Caue

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

Re: Feature request: #defines

Mike Wiering
Is there any way to include additional haxe options from a file (like with compile.hxml), when using the command line?

I'm using FlashDevelop and its great, but I hate having to go through menus and dialogs just to change a compiler directive and hardly having any space to edit them. I'd love to simply have a separate file in my project where I could turn them on or off (preferably allowing comments and whitespace), for example:


-D ShowURL
// -D DemoMode
-D MouseSupport
-D Sound

// -D MapEditor
// -D GenerateData

// -D ShowFPS

-D Cheats
// -D SkipLogo
// -D SkipMenus
// -D NoFading


I used to work in Delphi and had pages full of this stuff for larger projects.

Cheers,
Mike


On Fri, Jul 30, 2010 at 4:58 PM, Cauê Waneck <[hidden email]> wrote:

This is not best of usability, but you can still do the following :

#if !(HandleFiles || NotHandleFiles)
#error "Please specify either -D HandleFiles or -D NotHandleFiles"
#end

Got it!!

Thanks for the tip, will use that!

By the way, what about that package remapping on the haXe to-do's? For the next release, if you want, I could make the conditional typedefs so you can use haxe.io.File instead of (neko || cpp || php).io.File , etc


Cheers! Thanks
Caue

--
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: Feature request: #defines

Simon Krajewski
Hi,

you can always check the "no output" option in FD and add your own .hxml file as pre-build command (haxe.exe compile.hxml). I've been using empty FD projects with .hxml files for a while now, pretty much due to the exact same reason you stated.

Regards
Simon

Am 15.08.2010 15:53, schrieb Mike Wiering:
Is there any way to include additional haxe options from a file (like with compile.hxml), when using the command line?

I'm using FlashDevelop and its great, but I hate having to go through menus and dialogs just to change a compiler directive and hardly having any space to edit them. I'd love to simply have a separate file in my project where I could turn them on or off (preferably allowing comments and whitespace), for example:


-D ShowURL
// -D DemoMode
-D MouseSupport
-D Sound

// -D MapEditor
// -D GenerateData

// -D ShowFPS

-D Cheats
// -D SkipLogo
// -D SkipMenus
// -D NoFading


I used to work in Delphi and had pages full of this stuff for larger projects.

Cheers,
Mike


On Fri, Jul 30, 2010 at 4:58 PM, Cauê Waneck <[hidden email]> wrote:

This is not best of usability, but you can still do the following :

#if !(HandleFiles || NotHandleFiles)
#error "Please specify either -D HandleFiles or -D NotHandleFiles"
#end

Got it!!

Thanks for the tip, will use that!

By the way, what about that package remapping on the haXe to-do's? For the next release, if you want, I could make the conditional typedefs so you can use haxe.io.File instead of (neko || cpp || php).io.File , etc


Cheers! Thanks
Caue

--
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: Feature request: #defines

Mike Wiering
Thanks Simon, I just found out that it does work, if you simply add compile.hxml to the Additional compiler options. Commenting out lines doesn't work, but this is already a great improvement!

Cheers,
Mike


On Sun, Aug 15, 2010 at 5:09 PM, Simon Krajewski <[hidden email]> wrote:
Hi,

you can always check the "no output" option in FD and add your own .hxml file as pre-build command (haxe.exe compile.hxml). I've been using empty FD projects with .hxml files for a while now, pretty much due to the exact same reason you stated.

Regards
Simon

Am 15.08.2010 15:53, schrieb Mike Wiering:
Is there any way to include additional haxe options from a file (like with compile.hxml), when using the command line?

I'm using FlashDevelop and its great, but I hate having to go through menus and dialogs just to change a compiler directive and hardly having any space to edit them. I'd love to simply have a separate file in my project where I could turn them on or off (preferably allowing comments and whitespace), for example:


-D ShowURL
// -D DemoMode
-D MouseSupport
-D Sound

// -D MapEditor
// -D GenerateData

// -D ShowFPS

-D Cheats
// -D SkipLogo
// -D SkipMenus
// -D NoFading


I used to work in Delphi and had pages full of this stuff for larger projects.

Cheers,
Mike


On Fri, Jul 30, 2010 at 4:58 PM, Cauê Waneck <[hidden email]> wrote:

This is not best of usability, but you can still do the following :

#if !(HandleFiles || NotHandleFiles)
#error "Please specify either -D HandleFiles or -D NotHandleFiles"
#end

Got it!!

Thanks for the tip, will use that!

By the way, what about that package remapping on the haXe to-do's? For the next release, if you want, I could make the conditional typedefs so you can use haxe.io.File instead of (neko || cpp || php).io.File , etc


Cheers! Thanks
Caue

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Feature request: #defines

Cauê W.
you can comment lines of hxml files with #

2010/8/15 Mike Wiering <[hidden email]>
Thanks Simon, I just found out that it does work, if you simply add compile.hxml to the Additional compiler options. Commenting out lines doesn't work, but this is already a great improvement!

Cheers,
Mike


On Sun, Aug 15, 2010 at 5:09 PM, Simon Krajewski <[hidden email]> wrote:
Hi,

you can always check the "no output" option in FD and add your own .hxml file as pre-build command (haxe.exe compile.hxml). I've been using empty FD projects with .hxml files for a while now, pretty much due to the exact same reason you stated.

Regards
Simon

Am 15.08.2010 15:53, schrieb Mike Wiering:
Is there any way to include additional haxe options from a file (like with compile.hxml), when using the command line?

I'm using FlashDevelop and its great, but I hate having to go through menus and dialogs just to change a compiler directive and hardly having any space to edit them. I'd love to simply have a separate file in my project where I could turn them on or off (preferably allowing comments and whitespace), for example:


-D ShowURL
// -D DemoMode
-D MouseSupport
-D Sound

// -D MapEditor
// -D GenerateData

// -D ShowFPS

-D Cheats
// -D SkipLogo
// -D SkipMenus
// -D NoFading


I used to work in Delphi and had pages full of this stuff for larger projects.

Cheers,
Mike


On Fri, Jul 30, 2010 at 4:58 PM, Cauê Waneck <[hidden email]> wrote:

This is not best of usability, but you can still do the following :

#if !(HandleFiles || NotHandleFiles)
#error "Please specify either -D HandleFiles or -D NotHandleFiles"
#end

Got it!!

Thanks for the tip, will use that!

By the way, what about that package remapping on the haXe to-do's? For the next release, if you want, I could make the conditional typedefs so you can use haxe.io.File instead of (neko || cpp || php).io.File , etc


Cheers! Thanks
Caue

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


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

Re: Feature request: #defines

Mike Wiering
Great!

On Sun, Aug 15, 2010 at 5:46 PM, Cauê Waneck <[hidden email]> wrote:
you can comment lines of hxml files with #

2010/8/15 Mike Wiering <[hidden email]>

Thanks Simon, I just found out that it does work, if you simply add compile.hxml to the Additional compiler options. Commenting out lines doesn't work, but this is already a great improvement!

Cheers,
Mike


On Sun, Aug 15, 2010 at 5:09 PM, Simon Krajewski <[hidden email]> wrote:
Hi,

you can always check the "no output" option in FD and add your own .hxml file as pre-build command (haxe.exe compile.hxml). I've been using empty FD projects with .hxml files for a while now, pretty much due to the exact same reason you stated.

Regards
Simon

Am 15.08.2010 15:53, schrieb Mike Wiering:
Is there any way to include additional haxe options from a file (like with compile.hxml), when using the command line?

I'm using FlashDevelop and its great, but I hate having to go through menus and dialogs just to change a compiler directive and hardly having any space to edit them. I'd love to simply have a separate file in my project where I could turn them on or off (preferably allowing comments and whitespace), for example:


-D ShowURL
// -D DemoMode
-D MouseSupport
-D Sound

// -D MapEditor
// -D GenerateData

// -D ShowFPS

-D Cheats
// -D SkipLogo
// -D SkipMenus
// -D NoFading


I used to work in Delphi and had pages full of this stuff for larger projects.

Cheers,
Mike


On Fri, Jul 30, 2010 at 4:58 PM, Cauê Waneck <[hidden email]> wrote:

This is not best of usability, but you can still do the following :

#if !(HandleFiles || NotHandleFiles)
#error "Please specify either -D HandleFiles or -D NotHandleFiles"
#end

Got it!!

Thanks for the tip, will use that!

By the way, what about that package remapping on the haXe to-do's? For the next release, if you want, I could make the conditional typedefs so you can use haxe.io.File instead of (neko || cpp || php).io.File , etc


Cheers! Thanks
Caue

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


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


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