C++ stylistic concerns?

Brian Hawkins brianhks at activeclickweb.com
Thu Mar 22 10:39:46 MDT 2007


In my case I use a mac mini and a beefed up Linux box (I just put it 
together a few months ago and I still geek out over it).  My code 
resides on the linux box.  I mount the code directory on the mac.  I 
open up an ssh connection to the mac and use it to compile.  For windows 
I run VMWare on Linux.  Inside inside windows I map a drive to the code 
on the linux box.  If I really get into it I telnet to the windows vm 
from Linux.  Then I have three prompts that compile each platform with 
the native compiler.  Using the native compilers have advantages as 
there are features only the native compiler has.  For example the 
ability to compile ObjC++ code or the ability to create universal 
binaries is only available on the mac gcc.  On windows I can compile in 
a resource file and have a cute little icon for my exe. (not sure if I 
can do that with gcc)

Besides in most contract situations forcing your client to include mingw 
libraries in the final distribution does not go over well.  Natively 
compiled binaries tend to be the easiest to support.

I also do not like autoconf as it is a pain in the neck and it doesn't 
do windows very well.  That is why I created CPMake, it's purpose is to 
abstract the native compiler and create a build script that is easy to 
maintain and customize.

Brian

Michael L Torrie wrote:
> On Wed, 2007-03-21 at 17:59 -0600, Steve wrote:
>   
>> Oh good because this is turning into a nightmare of various IDE projects.
>>
>> Windows... Visual Studio 2k5 Express
>>
>> Linux, Code::Blocks (Make was choking at first, but doesn't now due to
>> the change in layout so I may switch back to makefiles for Linux.
>>
>> Mac, XCode (I really, really hate this IDE)
>>
>> If you have a good crossplatform development solution I would be much
>> obliged, since a unified build environment would speed things up
>> dramatically.
>>     
>
> I prefer to simply use GCC on all platforms.  I use autoconf usually,
> but it's a pain.  cmake might be a better tool.  On windows, the msys
> environment (mingw.org) gives enough of a unixy environment to satisfy
> most autoconf or other unix-oriented build systems.
>
> So normally I use my standard linux tools and then cross-compile for the
> windows target.  My last project was in Qt, and I hacked the spec file
> for win32 so it would work on linux, targeting the win32 compiler.  I
> also recently set up a complete cross-compiling environment that targets
> OS X from linux.  This made it easy with my Qt project to easily build
> all three platforms right on my linux box.  Note that my OS X target
> cross-compiler is PPC and 10.3 currently, but I do have the compilers
> installed that target both i386 and PPC 10.4, but I need to populate
> them with the header files and libraries from 10.4. For information on
> building the win32 cross-compiler, see
> http://www.torriefamily.org/~torriem/cross and for the Mac OS X
> cross-compiler (raw compiler with no platform headers or libraries) see
> http://ranger.befunk.com/fink/darwin-cross/ .  I hope to write up a
> summary of how to populate the libraries and header files in the
> darwin-cross system to generate full OS X exes.  
>
> So in summary, use GCC on all platforms! :)
>
> Michael
>
>
>   
>> Thanks!
>>
>> On 3/21/07, Brian Hawkins <brianhks at activeclickweb.com> wrote:
>>     
>>> Question:  what build tool(s) are you using on each platform?  The
>>> reason I ask is that I have one that kicks butt for writing cross
>>> platform code.
>>>
>>> Brian
>>>
>>> Steve wrote:
>>>       
>>>> Well I think I may have just figured out one reason for not doing it
>>>> this way.
>>>> Windows (Visual C++ .net 2005), is completely ignoring the namespace
>>>> constraint.
>>>> So my CreateWindow function was being confused by the compiler with
>>>> Windows own CreateWindow function.  Hence a lot of errors about
>>>> missing variables.
>>>> My guess is the compiler is treating the .h file using c syntax rules
>>>> rather than c++ syntax rules.
>>>> Changing my .h to a .cpp fixes the issue.
>>>> Thats a less than optimal solution though :(
>>>>
>>>> For what it's worth it's working like a charm on Mac and Linux.
>>>>
>>>> On 3/21/07, Michael L Torrie <torriem at chem.byu.edu> wrote:
>>>>         
>>>>> On Wed, 2007-03-21 at 10:45 -0600, Steve wrote:
>>>>>           
>>>>>> Thus far it's looking to be dual licensed, GPL (free) and
>>>>>> closed-commercial (fee of some sort)  Other than that I'm not sure and
>>>>>> don't much care, as long as the check clears :D
>>>>>>             
>>>>> This does make my last comments about OpenGL moot.  I still think they
>>>>> are way out in left field though.
>>>>>
>>>>>           
>>>>>
>>>>> /*
>>>>> PLUG: http://plug.org, #utah on irc.freenode.net
>>>>> Unsubscribe: http://plug.org/mailman/options/plug
>>>>> Don't fear the penguin.
>>>>> */
>>>>>
>>>>>           
>>>> /*
>>>> PLUG: http://plug.org, #utah on irc.freenode.net
>>>> Unsubscribe: http://plug.org/mailman/options/plug
>>>> Don't fear the penguin.
>>>> */
>>>>
>>>>         
>>> /*
>>> PLUG: http://plug.org, #utah on irc.freenode.net
>>> Unsubscribe: http://plug.org/mailman/options/plug
>>> Don't fear the penguin.
>>> */
>>>
>>>       
>> /*
>> PLUG: http://plug.org, #utah on irc.freenode.net
>> Unsubscribe: http://plug.org/mailman/options/plug
>> Don't fear the penguin.
>> */
>>
>>     
>
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>
>   



More information about the PLUG mailing list