Eclipse generator - basic macros

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

Eclipse generator - basic macros

Benjamin Schindler
Hi

I'm working on a project which builds both on linux and windows. I
generated an eclipse project out of it which works basically fine but
it's not able to recognize i.e. the __GNUC__ macro (and probably any
other macro defined per default on gcc) are not recognized by eclipse.
That means that by using a header like:

#if defined(_MSC_VER) && (_MSC_VER >= 1300)
#ifdef FLOW_DLL_EXPORT
#define FLOW_DLL _declspec(dllexport)
#else
#define FLOW_DLL _declspec(dllimport)
#endif
#else
#ifdef __GNUC__
#define FLOW_DLL
#endif
#endif

and then declaring a class like:

class FLOW_DLL something { .... };
will fool eclipse's parser. When I remove the #ifdef __GNUC__, it works.
Is this an issue in the eclipse generator or in the eclipse parser?

Thanks
Benjamin



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Miguel A. Figueroa-Villanueva
On Mon, Jul 13, 2009 at 10:31 AM, Benjamin Schindler wrote:

> Hi
>
> I'm working on a project which builds both on linux and windows. I generated
> an eclipse project out of it which works basically fine but it's not able to
> recognize i.e. the __GNUC__ macro (and probably any other macro defined per
> default on gcc) are not recognized by eclipse. That means that by using a
> header like:
>
> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
> #ifdef FLOW_DLL_EXPORT
> #define FLOW_DLL _declspec(dllexport)
> #else
> #define FLOW_DLL _declspec(dllimport)
> #endif
> #else
> #ifdef __GNUC__
> #define FLOW_DLL
> #endif
> #endif
>
> and then declaring a class like:
>
> class FLOW_DLL something { .... };
> will fool eclipse's parser. When I remove the #ifdef __GNUC__, it works. Is
> this an issue in the eclipse generator or in the eclipse parser?

The eclipse generator is an external generator... meaning that it uses
unix makefiles to compile in in linux with gcc. So, the project should
build properly, does it? If you go to the build directory and type
'make', does it build correctly?

The problem would still be present for the eclipse parser to support
the IDE browsing features. For example, it wil gray out the area when
it should not do so, etc. Is this what you mean by will fool the
parser?

--Miguel
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Benjamin Schindler
Miguel A. Figueroa-Villanueva wrote:

> On Mon, Jul 13, 2009 at 10:31 AM, Benjamin Schindler wrote:
>  
>> Hi
>>
>> I'm working on a project which builds both on linux and windows. I generated
>> an eclipse project out of it which works basically fine but it's not able to
>> recognize i.e. the __GNUC__ macro (and probably any other macro defined per
>> default on gcc) are not recognized by eclipse. That means that by using a
>> header like:
>>
>> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
>> #ifdef FLOW_DLL_EXPORT
>> #define FLOW_DLL _declspec(dllexport)
>> #else
>> #define FLOW_DLL _declspec(dllimport)
>> #endif
>> #else
>> #ifdef __GNUC__
>> #define FLOW_DLL
>> #endif
>> #endif
>>
>> and then declaring a class like:
>>
>> class FLOW_DLL something { .... };
>> will fool eclipse's parser. When I remove the #ifdef __GNUC__, it works. Is
>> this an issue in the eclipse generator or in the eclipse parser?
>>    
>
> The eclipse generator is an external generator... meaning that it uses
> unix makefiles to compile in in linux with gcc. So, the project should
> build properly, does it? If you go to the build directory and type
> 'make', does it build correctly?
>
> The problem would still be present for the eclipse parser to support
> the IDE browsing features. For example, it wil gray out the area when
> it should not do so, etc. Is this what you mean by will fool the
> parser?
>
> --Miguel
>  
Hi

Well, you are right about the greyed out area which is in short what I
ment (The project builds just fine). I would not mind this in any way,
but the issue is that classes utilizing that FLOW_DLL macro will be
marked with Syntax error (because that symbol is then not defined) and
thus, code completion is not available at all for these classes hich is
a big usability issue here

Thanks
Benjamin
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Michael Jackson

On Jul 14, 2009, at 11:40 AM, Benjamin Schindler wrote:

>>> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
>>> #ifdef FLOW_DLL_EXPORT
>>> #define FLOW_DLL _declspec(dllexport)
>>> #else
>>> #define FLOW_DLL _declspec(dllimport)
>>> #endif
>>> #else
>>> #ifdef __GNUC__
>>> #define FLOW_DLL
>>> #endif
>>> #endif



Not sure how dangerous this is _but_ when I have the same type of code  
for my windows code I don't explicitly define the __GNUC__ case  
because AFAIK MSVC is the only compiler that _I_ am using that needs  
this type of decoration. If this happens to be your case also then  
simply have the following:


#if defined(_MSC_VER) && (_MSC_VER >= 1300)
#ifdef FLOW_DLL_EXPORT
#define FLOW_DLL _declspec(dllexport)
#else
#define FLOW_DLL _declspec(dllimport)
#endif
#else
#define FLOW_DLL
#endif

If there are specific compilers that NEED to have FLOW_DLL defined to  
something that mimics MSVC (Like newer versions of GCC if you want to)  
then I would add specific #if defined (SOME_COMPILER) for that  
compiler. Any of that make sense?

---
Mike Jackson                 www.bluequartz.net



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Miguel A. Figueroa-Villanueva
In reply to this post by Benjamin Schindler
On Tue, Jul 14, 2009 at 11:40 AM, Benjamin Schindler wrote:

> Miguel A. Figueroa-Villanueva wrote:
>> On Mon, Jul 13, 2009 at 10:31 AM, Benjamin Schindler wrote:
>>> I'm working on a project which builds both on linux and windows. I
>>> generated
>>> an eclipse project out of it which works basically fine but it's not able
>>> to
>>> recognize i.e. the __GNUC__ macro (and probably any other macro defined
>>> per
>>> default on gcc) are not recognized by eclipse. That means that by using a
>>> header like:
>>>
>>> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
>>> #ifdef FLOW_DLL_EXPORT
>>> #define FLOW_DLL _declspec(dllexport)
>>> #else
>>> #define FLOW_DLL _declspec(dllimport)
>>> #endif
>>> #else
>>> #ifdef __GNUC__
>>> #define FLOW_DLL
>>> #endif
>>> #endif
>>>
>>> and then declaring a class like:
>>>
>>> class FLOW_DLL something { .... };
>>> will fool eclipse's parser. When I remove the #ifdef __GNUC__, it works.
>>> Is
>>> this an issue in the eclipse generator or in the eclipse parser?
>>>
[...]
>
> Well, you are right about the greyed out area which is in short what I ment
> (The project builds just fine). I would not mind this in any way, but the
> issue is that classes utilizing that FLOW_DLL macro will be marked with
> Syntax error (because that symbol is then not defined) and thus, code
> completion is not available at all for these classes hich is a big usability
> issue here

Yes, I'm well aware that this is a big usability problem... just
wanted to verify the source of the problem.

Ok, maybe you can work around this by adding a snippet such as:

if (UNIX) # or if (CMAKE_COMPILER_IS_GNUC)
  add_definitions(__GNUC__)
  # actually, I would use a different variable here and change the code above
endif

Then the variable should be added to the project files. Please let me
know if this works.

--Miguel
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Alexander Neundorf-3
On Tuesday 14 July 2009, Miguel A. Figueroa-Villanueva wrote:

> On Tue, Jul 14, 2009 at 11:40 AM, Benjamin Schindler wrote:
> > Miguel A. Figueroa-Villanueva wrote:
> >> On Mon, Jul 13, 2009 at 10:31 AM, Benjamin Schindler wrote:
> >>> I'm working on a project which builds both on linux and windows. I
> >>> generated
> >>> an eclipse project out of it which works basically fine but it's not
> >>> able to
> >>> recognize i.e. the __GNUC__ macro (and probably any other macro defined
> >>> per
> >>> default on gcc) are not recognized by eclipse. That means that by using
> >>> a header like:
> >>>
> >>> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
> >>> #ifdef FLOW_DLL_EXPORT
> >>> #define FLOW_DLL _declspec(dllexport)
> >>> #else
> >>> #define FLOW_DLL _declspec(dllimport)
> >>> #endif
> >>> #else
> >>> #ifdef __GNUC__
> >>> #define FLOW_DLL
> >>> #endif
> >>> #endif
> >>>
> >>> and then declaring a class like:
> >>>
> >>> class FLOW_DLL something { .... };
> >>> will fool eclipse's parser. When I remove the #ifdef __GNUC__, it
> >>> works. Is
> >>> this an issue in the eclipse generator or in the eclipse parser?
>
> [...]
>
> > Well, you are right about the greyed out area which is in short what I
> > ment (The project builds just fine). I would not mind this in any way,
> > but the issue is that classes utilizing that FLOW_DLL macro will be
> > marked with Syntax error (because that symbol is then not defined) and
> > thus, code completion is not available at all for these classes hich is a
> > big usability issue here
>
> Yes, I'm well aware that this is a big usability problem... just
> wanted to verify the source of the problem.
>
> Ok, maybe you can work around this by adding a snippet such as:
>
> if (UNIX) # or if (CMAKE_COMPILER_IS_GNUC)
>   add_definitions(__GNUC__)
>   # actually, I would use a different variable here and change the code
> above endif
>
> Then the variable should be added to the project files. Please let me
> know if this works.

We already query gcc for the system include dirs, do we also need to query it
for the builtin macros and put that information somewhere ?

Alex
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Michael Jackson
  Jul 14, 2009, at 2:26 PM, Alexander Neundorf wrote:

> On Tuesday 14 July 2009, Miguel A. Figueroa-Villanueva wrote:
>> On Tue, Jul 14, 2009 at 11:40 AM, Benjamin Schindler wrote:
>>> Miguel A. Figueroa-Villanueva wrote:
>>>> On Mon, Jul 13, 2009 at 10:31 AM, Benjamin Schindler wrote:
>>>>> I'm working on a project which builds both on linux and windows. I
>>>>> generated
>>>>> an eclipse project out of it which works basically fine but it's  
>>>>> not
>>>>> able to
>>>>> recognize i.e. the __GNUC__ macro (and probably any other macro  
>>>>> defined
>>>>> per
>>>>> default on gcc) are not recognized by eclipse. That means that  
>>>>> by using
>>>>> a header like:
>>>>>
>>>>> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
>>>>> #ifdef FLOW_DLL_EXPORT
>>>>> #define FLOW_DLL _declspec(dllexport)
>>>>> #else
>>>>> #define FLOW_DLL _declspec(dllimport)
>>>>> #endif
>>>>> #else
>>>>> #ifdef __GNUC__
>>>>> #define FLOW_DLL
>>>>> #endif
>>>>> #endif
>>>>>
>>>>> and then declaring a class like:
>>>>>
>>>>> class FLOW_DLL something { .... };
>>>>> will fool eclipse's parser. When I remove the #ifdef __GNUC__, it
>>>>> works. Is
>>>>> this an issue in the eclipse generator or in the eclipse parser?
>>
>> [...]
>>
>>> Well, you are right about the greyed out area which is in short  
>>> what I
>>> ment (The project builds just fine). I would not mind this in any  
>>> way,
>>> but the issue is that classes utilizing that FLOW_DLL macro will be
>>> marked with Syntax error (because that symbol is then not defined)  
>>> and
>>> thus, code completion is not available at all for these classes  
>>> hich is a
>>> big usability issue here
>>
>> Yes, I'm well aware that this is a big usability problem... just
>> wanted to verify the source of the problem.
>>
>> Ok, maybe you can work around this by adding a snippet such as:
>>
>> if (UNIX) # or if (CMAKE_COMPILER_IS_GNUC)
>>  add_definitions(__GNUC__)
>>  # actually, I would use a different variable here and change the  
>> code
>> above endif
>>
>> Then the variable should be added to the project files. Please let me
>> know if this works.
>
> We already query gcc for the system include dirs, do we also need to  
> query it
> for the builtin macros and put that information somewhere ?
>
> Alex

Using the form I sent earlier I do not have any of these problems. All  
my source files are parsed and indexed correctly. Am I missing  
something or doing something wrong?

Mike Jackson


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Miguel A. Figueroa-Villanueva
On Tue, Jul 14, 2009 at 2:39 PM, Michael Jackson wrote:
> Using the form I sent earlier I do not have any of these problems. All my
> source files are parsed and indexed correctly. Am I missing something or
> doing something wrong?
>
> Mike Jackson

Hello Mike,

Well, I see it as a viable workaround, but only if you use eclipse
only with gcc. In the case where you might use nmake/eclipse, then it
won't work.

So, I would prefer to work around it by handling compiler specific
stuff with CMake magic and ideally we can use the same gcc probing
technique that is being used for the include files.

So Benjamin, could you check if the cmake workaround actually works
and mybe you would like to open a feature request to use the gcc
probing method to automatically include compiler specific definitions
in the .cproject.

--Miguel
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Michael Jackson
  If you are using nmake then you are using MSVC which means you would  
drop down into the #if defined (_MSVC_VER) block. At that point  
FLOW_DLL is going to be defined as either the import or export version  
neither of which I have any faith that CDT Would be able to parse any  
way (or it might but I am not holding my breath). So my guess is that  
it is not going to work but not because of CMake or anything else, it  
would probably be CDT's fault.

And if you _are_ using nmake successfully with CDT, how are you doing  
that. I have tried more than a few times to set that up all without  
any luck.

** I am also assuming you mean the nmake that comes with Visual Studio  
and not the nmake that comes with UWin from AT&T....

---
Mike Jackson                 www.bluequartz.net



On Jul 14, 2009, at 3:10 PM, Miguel A. Figueroa-Villanueva wrote:

> Well, I see it as a viable workaround, but only if you use eclipse
> only with gcc. In the case where you might use nmake/eclipse, then it
> won't work.

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Michael Jackson
So. I'll take my foot out of my mouth now. I actually got CDT 6.0 to
work with nmake (from VS 2008 Express). Now if I could just calm down
the warning level that would make things readable.

And the form that I use to control the DLL import and export seems to
work also.

Mike

On Tue, Jul 14, 2009 at 3:18 PM, Michael
Jackson<[hidden email]> wrote:

>  If you are using nmake then you are using MSVC which means you would drop
> down into the #if defined (_MSVC_VER) block. At that point FLOW_DLL is going
> to be defined as either the import or export version neither of which I have
> any faith that CDT Would be able to parse any way (or it might but I am not
> holding my breath). So my guess is that it is not going to work but not
> because of CMake or anything else, it would probably be CDT's fault.
>
> And if you _are_ using nmake successfully with CDT, how are you doing that.
> I have tried more than a few times to set that up all without any luck.
>
> ** I am also assuming you mean the nmake that comes with Visual Studio and
> not the nmake that comes with UWin from AT&T....
>
> ---
> Mike Jackson                 www.bluequartz.net
>
>
>
> On Jul 14, 2009, at 3:10 PM, Miguel A. Figueroa-Villanueva wrote:
>
>> Well, I see it as a viable workaround, but only if you use eclipse
>> only with gcc. In the case where you might use nmake/eclipse, then it
>> won't work.
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Benjamin Schindler
In reply to this post by Miguel A. Figueroa-Villanueva
Hi

That workaround works - I've done it when I sent the initial mail. But I
can imagine various situation when this can become an issue as well
(like when writing compiler or platform specific code), so I posted it
here anyway to start a discussion.
 I think the probing for defined macros like you do for the includes
(that makes things like heaven compared to <2.6.4!!) would solve it
nicely IMHO.

Thanks
Benjamin

Miguel A. Figueroa-Villanueva wrote:

> On Tue, Jul 14, 2009 at 2:39 PM, Michael Jackson wrote:
>  
>> Using the form I sent earlier I do not have any of these problems. All my
>> source files are parsed and indexed correctly. Am I missing something or
>> doing something wrong?
>>
>> Mike Jackson
>>    
>
> Hello Mike,
>
> Well, I see it as a viable workaround, but only if you use eclipse
> only with gcc. In the case where you might use nmake/eclipse, then it
> won't work.
>
> So, I would prefer to work around it by handling compiler specific
> stuff with CMake magic and ideally we can use the same gcc probing
> technique that is being used for the include files.
>
> So Benjamin, could you check if the cmake workaround actually works
> and mybe you would like to open a feature request to use the gcc
> probing method to automatically include compiler specific definitions
> in the .cproject.
>
> --Miguel
>  
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Miguel A. Figueroa-Villanueva
In reply to this post by Michael Jackson
On Tue, Jul 14, 2009 at 3:26 PM, Mike Jackson wrote:

> On Tue, Jul 14, 2009 at 3:18 PM, Michael Jackson wrote:
>> On Jul 14, 2009, at 3:10 PM, Miguel A. Figueroa-Villanueva wrote:
>>
>>> Well, I see it as a viable workaround, but only if you use eclipse
>>> only with gcc. In the case where you might use nmake/eclipse, then it
>>> won't work.
>>
>>  If you are using nmake then you are using MSVC which means you would drop
>> down into the #if defined (_MSVC_VER) block. At that point FLOW_DLL is going
>> to be defined as either the import or export version neither of which I have
>> any faith that CDT Would be able to parse any way (or it might but I am not
>> holding my breath). So my guess is that it is not going to work but not
>> because of CMake or anything else, it would probably be CDT's fault.
>>
>> And if you _are_ using nmake successfully with CDT, how are you doing that.
>> I have tried more than a few times to set that up all without any luck.
>>
>> ** I am also assuming you mean the nmake that comes with Visual Studio and
>> not the nmake that comes with UWin from AT&T....
>>
> So. I'll take my foot out of my mouth now. I actually got CDT 6.0 to
> work with nmake (from VS 2008 Express). Now if I could just calm down
> the warning level that would make things readable.

I'm glad it works, I'm not using it ;)

I just remember that when I wrote the generator I intended it to be
useful as an extension to the Unix, MinGW, and NMake Makefiles
generators.

We can certainly use help in testing, so report any things you find
that are bugs or in any way lacking.

> And the form that I use to control the DLL import and export seems to
> work also.

Yes, I misread your approach; your right. However, as you indicate it
only works in this case, but you can't use this approach to do
compiler dependent conditionals in general.

--Miguel
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Miguel A. Figueroa-Villanueva
In reply to this post by Benjamin Schindler
On Tue, Jul 14, 2009 at 6:55 PM, Benjamin Schindler wrote:
> Hi
>
> That workaround works - I've done it when I sent the initial mail. But I can
> imagine various situation when this can become an issue as well (like when
> writing compiler or platform specific code), so I posted it here anyway to
> start a discussion.
> I think the probing for defined macros like you do for the includes (that
> makes things like heaven compared to <2.6.4!!) would solve it nicely IMHO.

Just to be clear...

If you have compiler dependent code:

#if defined(_MSC_VER)
...
#elif defined(__GNUC__)
...
#else
...
#endif

Then you could do something like the following in CMakeLists.txt:

if (CMAKE_COMPILER_IS_GNUC)
  add_definitions(-DWORKING_WITH_GCC) # or use COMPILE_DEFINITIONS property
elseif (MSVC)
  add_definitions(-DWORKING_WITH_MSVC) # or use COMPILE_DEFINITIONS property
endif()

and the code above would look like:

#if defined(WORKING_WITH_MSVC)
...
#elif defined(WORKING_WITH_GCC)
...
#else
...
#endif

The only limitation that I see for compiler/platform specific stuff is
that CMake needs to be able to differentiate somehow between them...
right? or am I missing something else?

--Miguel
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Benjamin Schindler


Miguel A. Figueroa-Villanueva wrote:

> On Tue, Jul 14, 2009 at 6:55 PM, Benjamin Schindler wrote:
>  
>> Hi
>>
>> That workaround works - I've done it when I sent the initial mail. But I can
>> imagine various situation when this can become an issue as well (like when
>> writing compiler or platform specific code), so I posted it here anyway to
>> start a discussion.
>> I think the probing for defined macros like you do for the includes (that
>> makes things like heaven compared to <2.6.4!!) would solve it nicely IMHO.
>>    
>
> Just to be clear...
>
> If you have compiler dependent code:
>
> #if defined(_MSC_VER)
> ...
> #elif defined(__GNUC__)
> ...
> #else
> ...
> #endif
>
> Then you could do something like the following in CMakeLists.txt:
>
> if (CMAKE_COMPILER_IS_GNUC)
>   add_definitions(-DWORKING_WITH_GCC) # or use COMPILE_DEFINITIONS property
> elseif (MSVC)
>   add_definitions(-DWORKING_WITH_MSVC) # or use COMPILE_DEFINITIONS property
> endif()
>
> and the code above would look like:
>
> #if defined(WORKING_WITH_MSVC)
> ...
> #elif defined(WORKING_WITH_GCC)
> ...
> #else
> ...
> #endif
>  
Yes, I could do that. But that's a hack - it should not be needed. All
compilers have their macros which enables to differentiate between them,
so why adding a new one?
> The only limitation that I see for compiler/platform specific stuff is
> that CMake needs to be able to differentiate somehow between them...
> right? or am I missing something else?
>
> --Miguel
>  
Thanks
Benjamin
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Miguel A. Figueroa-Villanueva
On Tue, Jul 14, 2009 at 7:46 PM, Benjamin Schindler wrote:

> Miguel A. Figueroa-Villanueva wrote:
>> Just to be clear...
>>
>> If you have compiler dependent code:
>>
>> #if defined(_MSC_VER)
>> ...
>> #elif defined(__GNUC__)
>> ...
>> #else
>> ...
>> #endif
>>
>> Then you could do something like the following in CMakeLists.txt:
>>
>> if (CMAKE_COMPILER_IS_GNUC)
>>  add_definitions(-DWORKING_WITH_GCC) # or use COMPILE_DEFINITIONS property
>> elseif (MSVC)
>>  add_definitions(-DWORKING_WITH_MSVC) # or use COMPILE_DEFINITIONS
>> property
>> endif()
>>
>> and the code above would look like:
>>
>> #if defined(WORKING_WITH_MSVC)
>> ...
>> #elif defined(WORKING_WITH_GCC)
>> ...
>> #else
>> ...
>> #endif
>>
>
> Yes, I could do that. But that's a hack - it should not be needed. All
> compilers have their macros which enables to differentiate between them, so
> why adding a new one?

Right, it is a hack (after all it is a work around) I was just curious
to know where it wouldn't work... and I also wanted to make sure that
the eclipse generator is feeding the manually added definitions
correctly to the IDE.

However, please do add this as a feature request at:

http://public.kitware.com/Bug/my_view_page.php

The following lines seem to dump the needed information:

echo | gcc -v -x c -E -dD -
echo | gcc -v -x c++ -E -dD -

Add any other relevant information; even patches are welcome ;)

--Miguel
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Hendrik Sattler
In reply to this post by Benjamin Schindler
Zitat von Benjamin Schindler <[hidden email]>:

> I'm working on a project which builds both on linux and windows. I
> generated an eclipse project out of it which works basically fine but
> it's not able to recognize i.e. the __GNUC__ macro (and probably any
> other macro defined per default on gcc) are not recognized by eclipse.
> That means that by using a header like:
>
> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
> #ifdef FLOW_DLL_EXPORT
> #define FLOW_DLL _declspec(dllexport)
> #else
> #define FLOW_DLL _declspec(dllimport)
> #endif
> #else
> #ifdef __GNUC__
> #define FLOW_DLL
> #endif
> #endif

I know that it's unrelated to your question but this code is slightly wrong.
For the windows version of gcc, it also understands the _declspec()  
thing. You don't make it compiler-specific but system-specific.
Additionally, on non-windows systems, you can use the visibility  
attribute to achieve something similar.
That's why the gcc people suggest the following at
http://gcc.gnu.org/wiki/Visibility (I simplified it):
#if defined _WIN32 || defined __CYGWIN__
   #ifdef FLOW_DLL_EXPORT
     #define FLOW_DLL __declspec(dllexport)
   #else
     #define FLOW_DLL __declspec(dllimport)
   #endif
#elif __GNUC__ >= 4
   #define FLOW_DLL __attribute__ ((visibility("default")))
   #define DLL_LOCAL  __attribute__ ((visibility("hidden")))
#endif
#ifndef FLOW_DLL
#define FLOW_DLL
#endif
#ifndef DLL_LOCAL
#define DLL_LOCAL
#endif

You only need to add -fvisibility=hidden to gcc command line on  
non-windows systems.
The above still has the flaw you use _declspec(dllimport) when  
compiling the library as static library. That's ok if you don't intend  
to do so else easy to fix.

Additionally, eclipse may not select the right choice but the macros  
will not error out as they are _always_ defined in some way.

Have fun

HS


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Benjamin Schindler
Hei, thanks for the thorough review and hints. I'll surely apply them

Thanks
Benjamin

Hendrik Sattler wrote:

> Zitat von Benjamin Schindler <[hidden email]>:
>> I'm working on a project which builds both on linux and windows. I
>> generated an eclipse project out of it which works basically fine but
>> it's not able to recognize i.e. the __GNUC__ macro (and probably any
>> other macro defined per default on gcc) are not recognized by eclipse.
>> That means that by using a header like:
>>
>> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
>> #ifdef FLOW_DLL_EXPORT
>> #define FLOW_DLL _declspec(dllexport)
>> #else
>> #define FLOW_DLL _declspec(dllimport)
>> #endif
>> #else
>> #ifdef __GNUC__
>> #define FLOW_DLL
>> #endif
>> #endif
>
> I know that it's unrelated to your question but this code is slightly
> wrong.
> For the windows version of gcc, it also understands the _declspec()
> thing. You don't make it compiler-specific but system-specific.
> Additionally, on non-windows systems, you can use the visibility
> attribute to achieve something similar.
> That's why the gcc people suggest the following at
> http://gcc.gnu.org/wiki/Visibility (I simplified it):
> #if defined _WIN32 || defined __CYGWIN__
>   #ifdef FLOW_DLL_EXPORT
>     #define FLOW_DLL __declspec(dllexport)
>   #else
>     #define FLOW_DLL __declspec(dllimport)
>   #endif
> #elif __GNUC__ >= 4
>   #define FLOW_DLL __attribute__ ((visibility("default")))
>   #define DLL_LOCAL  __attribute__ ((visibility("hidden")))
> #endif
> #ifndef FLOW_DLL
> #define FLOW_DLL
> #endif
> #ifndef DLL_LOCAL
> #define DLL_LOCAL
> #endif
>
> You only need to add -fvisibility=hidden to gcc command line on
> non-windows systems.
> The above still has the flaw you use _declspec(dllimport) when
> compiling the library as static library. That's ok if you don't intend
> to do so else easy to fix.
>
> Additionally, eclipse may not select the right choice but the macros
> will not error out as they are _always_ defined in some way.
>
> Have fun
>
> HS
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Michael Jackson
In reply to this post by Hendrik Sattler
On Wed, Jul 15, 2009 at 2:18 AM, Hendrik Sattler<[hidden email]> wrote:

> Zitat von Benjamin Schindler <[hidden email]>:
>>
>> I'm working on a project which builds both on linux and windows. I
>> generated an eclipse project out of it which works basically fine but
>> it's not able to recognize i.e. the __GNUC__ macro (and probably any
>> other macro defined per default on gcc) are not recognized by eclipse.
>> That means that by using a header like:
>>
>> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
>> #ifdef FLOW_DLL_EXPORT
>> #define FLOW_DLL _declspec(dllexport)
>> #else
>> #define FLOW_DLL _declspec(dllimport)
>> #endif
>> #else
>> #ifdef __GNUC__
>> #define FLOW_DLL
>> #endif
>> #endif
>
> I know that it's unrelated to your question but this code is slightly wrong.
> For the windows version of gcc, it also understands the _declspec() thing.
> You don't make it compiler-specific but system-specific.
> Additionally, on non-windows systems, you can use the visibility attribute
> to achieve something similar.
> That's why the gcc people suggest the following at
> http://gcc.gnu.org/wiki/Visibility (I simplified it):
> #if defined _WIN32 || defined __CYGWIN__
>  #ifdef FLOW_DLL_EXPORT
>    #define FLOW_DLL __declspec(dllexport)
>  #else
>    #define FLOW_DLL __declspec(dllimport)
>  #endif
> #elif __GNUC__ >= 4
>  #define FLOW_DLL __attribute__ ((visibility("default")))
>  #define DLL_LOCAL  __attribute__ ((visibility("hidden")))
> #endif
> #ifndef FLOW_DLL
> #define FLOW_DLL
> #endif
> #ifndef DLL_LOCAL
> #define DLL_LOCAL
> #endif
>
> You only need to add -fvisibility=hidden to gcc command line on non-windows
> systems.
> The above still has the flaw you use _declspec(dllimport) when compiling the
> library as static library. That's ok if you don't intend to do so else easy
> to fix.
>
> Additionally, eclipse may not select the right choice but the macros will
> not error out as they are _always_ defined in some way.
>
> Have fun
>
> HS

I think I need some explanation on this logic.

This line:

#if defined _WIN32 || defined __CYGWIN__

will always be true on msvc, mingw and cygwin because _WIN32 is
defined for the MS compilers and when MinGW is being used so the
"#elif" will _never_ get executed? Where am I going wrong on this?

I put the following at the top of a source file and compiled with
MinGW and got an error:

#ifdef _WIN32
#error Um what is wrong
#endif

 I looked at the GCC page cited above and I think it would have the
same problem.

Mike


--
Mike Jackson                               [hidden email]
BlueQuartz Software                    www.bluequartz.net
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Hendrik Sattler
Am Mittwoch 15 Juli 2009 17:21:38 schrieb Mike Jackson:
> On Wed, Jul 15, 2009 at 2:18 AM, Hendrik Sattler<[hidden email]>
wrote:

> > Zitat von Benjamin Schindler <[hidden email]>:
> >> I'm working on a project which builds both on linux and windows. I
> >> generated an eclipse project out of it which works basically fine but
> >> it's not able to recognize i.e. the __GNUC__ macro (and probably any
> >> other macro defined per default on gcc) are not recognized by eclipse.
> >> That means that by using a header like:
> >>
> >> #if defined(_MSC_VER) && (_MSC_VER >= 1300)
> >> #ifdef FLOW_DLL_EXPORT
> >> #define FLOW_DLL _declspec(dllexport)
> >> #else
> >> #define FLOW_DLL _declspec(dllimport)
> >> #endif
> >> #else
> >> #ifdef __GNUC__
> >> #define FLOW_DLL
> >> #endif
> >> #endif
> >
> > I know that it's unrelated to your question but this code is slightly
> > wrong. For the windows version of gcc, it also understands the
> > _declspec() thing. You don't make it compiler-specific but
> > system-specific.
> > Additionally, on non-windows systems, you can use the visibility
> > attribute to achieve something similar.
> > That's why the gcc people suggest the following at
> > http://gcc.gnu.org/wiki/Visibility (I simplified it):
> > #if defined _WIN32 || defined __CYGWIN__
> >  #ifdef FLOW_DLL_EXPORT
> >    #define FLOW_DLL __declspec(dllexport)
> >  #else
> >    #define FLOW_DLL __declspec(dllimport)
> >  #endif
> > #elif __GNUC__ >= 4
> >  #define FLOW_DLL __attribute__ ((visibility("default")))
> >  #define DLL_LOCAL  __attribute__ ((visibility("hidden")))
> > #endif
> > #ifndef FLOW_DLL
> > #define FLOW_DLL
> > #endif
> > #ifndef DLL_LOCAL
> > #define DLL_LOCAL
> > #endif
> >
> > You only need to add -fvisibility=hidden to gcc command line on
> > non-windows systems.
> > The above still has the flaw you use _declspec(dllimport) when compiling
> > the library as static library. That's ok if you don't intend to do so
> > else easy to fix.
> >
> > Additionally, eclipse may not select the right choice but the macros will
> > not error out as they are _always_ defined in some way.
> >
> > Have fun
> >
> > HS
>
> I think I need some explanation on this logic.
>
> This line:
>
> #if defined _WIN32 || defined __CYGWIN__
>
> will always be true on msvc, mingw and cygwin because _WIN32 is
> defined for the MS compilers and when MinGW is being used so the
> "#elif" will _never_ get executed? Where am I going wrong on this?

You don't. It is always right on Windows, at least with all MSVC and gcc
compilers. Using any MSVC older that 7 (.NET 2003) is insane and that works
there.
The elif case if for systems like Linux with GCC >= 4.

HS

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse generator - basic macros

Alexander Neundorf-3
In reply to this post by Miguel A. Figueroa-Villanueva
On Wednesday 15 July 2009, Miguel A. Figueroa-Villanueva wrote:

> On Tue, Jul 14, 2009 at 7:46 PM, Benjamin Schindler wrote:
> > Miguel A. Figueroa-Villanueva wrote:
> >> Just to be clear...
> >>
> >> If you have compiler dependent code:
> >>
> >> #if defined(_MSC_VER)
> >> ...
> >> #elif defined(__GNUC__)
> >> ...
> >> #else
> >> ...
> >> #endif
> >>
> >> Then you could do something like the following in CMakeLists.txt:
> >>
> >> if (CMAKE_COMPILER_IS_GNUC)
> >>  add_definitions(-DWORKING_WITH_GCC) # or use COMPILE_DEFINITIONS
> >> property elseif (MSVC)
> >>  add_definitions(-DWORKING_WITH_MSVC) # or use COMPILE_DEFINITIONS
> >> property
> >> endif()
> >>
> >> and the code above would look like:
> >>
> >> #if defined(WORKING_WITH_MSVC)
> >> ...
> >> #elif defined(WORKING_WITH_GCC)
> >> ...
> >> #else
> >> ...
> >> #endif
> >
> > Yes, I could do that. But that's a hack - it should not be needed. All
> > compilers have their macros which enables to differentiate between them,
> > so why adding a new one?
>
> Right, it is a hack (after all it is a work around) I was just curious
> to know where it wouldn't work... and I also wanted to make sure that
> the eclipse generator is feeding the manually added definitions
> correctly to the IDE.
>
> However, please do add this as a feature request at:
>
> http://public.kitware.com/Bug/my_view_page.php
>
> The following lines seem to dump the needed information:
>
> echo | gcc -v -x c -E -dD -
> echo | gcc -v -x c++ -E -dD -
>
> Add any other relevant information; even patches are welcome ;)

Once I have the list of builtin macros, how should they end up in the project
files ?
Do you have any example files or pointers to documentation ?
Here's the entry in the bug tracker:
http://public.kitware.com/Bug/view.php?id=9272

Alex
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake