Open Protektor-Desura opened 12 years ago
This would require issue #80 implemented.
an interesting point I forgot to mention in the past: Does desurium compiles with the clang compiler? It can be tried with my fork easily (I am currently at work, so I can't check this):
mkdir build cd build CC=clang CXX=clang++ cmake .. make
It is possible to install a newer gcc version on Mac OS X, but by default (with the normal Xcode install) there are only the old gcc (4.2.1 with Apple patches, but without C++0x features), llvm-gcc and clang.
Well the biggest chunk of stuff CEF is supported officially with a Mac version. http://code.google.com/p/chromiumembedded/
it seems that CEF is supported to build with clang
http://code.google.com/p/chromium/wiki/Clang
this will make things much easier, because there is no need of a newer gcc on Mac OS X. When I'm home, I will try to build desurium with clang on Linux (without CEF).
error while building breakpad with clang:
libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I/home/karol/Dokumente/repos/Desurium/build/breakpad-prefix/src/breakpad -I./src -I/home/karol/Dokumente/repos/Desurium/build/breakpad-prefix/src/breakpad/src -g -O2 -MT src/client/linux/crash_generation/crash_generation_client.lo -MD -MP -MF src/client/linux/crash_generation/.deps/crash_generation_client.Tpo -c /home/karol/Dokumente/repos/Desurium/build/breakpad-prefix/src/breakpad/src/client/linux/crash_generation/crash_generation_client.cc -o src/client/linux/crash_generation/crash_generation_client.o /home/karol/Dokumente/repos/Desurium/build/breakpad-prefix/src/breakpad/src/client/linux/crash_generation/crash_generation_client.cc:39:10: fatal error: 'third_party/lss/linux_syscall_support.h' file not found
Looks like that will need to be fixed or replaced for the future Mac client.
Protektor you should hang in IRC some more.
I will try and remember to open my IRC client more often.
it seems that clang 3.0 does not support lambda expressions:
http://clang.llvm.org/cxx_status.html
But we can get around lamda expressions using BOOST_FOREACH macros (I think the only use of lambda expressions in desurium is within std::for_each ?)
Other possibilities are:
example for BOOST_FOREACH:
src/include/Event.h:
EventBase<TArg, TDel>& operator=(const EventBase<TArg, TDel>& e)
{
m_vDelegates = e.m_vDelegates;
std::for_each(e.m_vDelegates.begin(), e.m_vDelegates.end(), [&](TDel* pDel)
{
this->m_vDelegates.push_back(pDel->clone());
});
return *this;
}
will turn to
#include <boost/for_each.hpp>
EventBase<TArg, TDel>& operator=(const EventBase<TArg, TDel>& e)
{
m_vDelegates = e.m_vDelegates;
BOOST_FOREACH(TDel* pDEL, e.m_vDelegates)
{
this->m_vDelegates.push_back(pDel->clone());
}
return *this;
}
or
#ifdef __clang__
# include <boost/for_each.hpp>
#endif
EventBase<TArg, TDel>& operator=(const EventBase<TArg, TDel>& e)
{
m_vDelegates = e.m_vDelegates;
#ifdef __clang__
BOOST_FOREACH(TDel* pDEL, e.m_vDelegates)
#else
std::for_each(e.m_vDelegates.begin(), e.m_vDelegates.end(), [&](TDel* pDel)
#endif
{
this->m_vDelegates.push_back(pDel->clone());
}
#ifndef __clang__
);
#endif
return *this;
}
I don't like the idea of compiler-based code switching hackery. It looks like a right place for bugs to nest. I say we just use BOOST_FOREACH and comment out the old code until Clang 3.1.
I would prefer this solution, too
karolherbst lambdas are used for much more. Dont like Boost for each ether
I should mention that the server now completely supports Mac, so we only need the client created and the backend is ready to go.
for a clang build we have to do some work in wxWidgets
In file included from /home/karol/Dokumente/repos/Desurium/src/static/managers/code/WindowManager.cpp:21:
In file included from /home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/wx.h:16:
In file included from /home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/object.h:20:
In file included from /home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/memory.h:16:
In file included from /home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/string.h:53:
In file included from /home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/strvararg.h:21:
In file included from /home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/strconv.h:18:
/home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/buffer.h:302:9: error: use of undeclared identifier 'MakeOwnedCopyOf'
MakeOwnedCopyOf(src);
^
this->
/home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/buffer.h:357:11: note: in instantiation of member function 'wxCharTypeBuffer<char>::wxCharTypeBuffer' requested here
: wxCharTypeBufferBase(buf) {}
^
/home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/buffer.h:210:10: note: must qualify identifier to find this declaration in dependent base class
void MakeOwnedCopyOf(const wxScopedCharTypeBuffer& src)
^
/home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/buffer.h:267:37: error: use of undeclared identifier 'StrCopy'
this->m_data = new Data(StrCopy(str, len), len);
^
this->
/home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/buffer.h:359:48: note: in instantiation of member function 'wxCharTypeBuffer<char>::wxCharTypeBuffer' requested here
wxCharBuffer(const CharType *str = NULL) : wxCharTypeBufferBase(str) {}
^
/home/karol/Dokumente/repos/Desurium/build/external/wxWidgets/include/wx-2.9-desura/wx/buffer.h:236:22: note: must qualify identifier to find this declaration in dependent base class
static CharType *StrCopy(const CharType *src, size_t len)
^
seems to be an error like #163
Desura compiles with clang on Linux now:
https://github.com/karolherbst/Desurium/tree/clang
I will check how stable it is
okay it is running with clang 3.1-svn
note:
alle external builds are building with system default compiler (so gcc here)
just checking... is this bug still unresolved?
Nat from lindenlab is working on this
Eventually I would like to see the client ported to Mac. We are already supporting Mac on the server side. Almost everything is setup on the back-end to support a Mac client. We would just need to add a few things to recognize the Mac client and show the right stuff to the Mac client I believe. We already allow Mac downloads from the website.
I would assume that the sooner it is done the easier it will be when new features are added to the client since you won't have to go back and add Mac compatibility to everything. Now seems like a very good time to add the Mac code/port.
The first thing would be getting the basic UI of the top inch or so of the window for features. The rest is CEF currently if I understand correctly. You would need to get Uploads/Downloads/Updates working which I wouldn't think would be too hard since you could re-use some/most of the Linux code. The pull down menu and tabs would be part of the GUI. The guts/logic I would assume you could re-use all the Linux stuff.