I just checked in some fixes: Committed revision 128720. Committed revision 128721.
Does this take care of all your issues? I will respond about the thread ID one in a separate email. Greg Clayton On Apr 1, 2011, at 11:22 AM, Amit Kulkarni wrote: >> I think using ULLONG_MAX and friends makes sense. For platforms that do >> not define them we can easily provide our own in a config.h. >> > > OK, I will resend a diff with LLONG_MAX and ULLONG_MAX only. > >>> 2) File.cpp needs <sys/stat.h> because all the permissions like >>> S_IRUSR, S_IWUSR, S_IROTH, S_IXOTH etc are defined there in OpenBSD >>> and FreeBSD (both -current or head sources). I don't have any Linux >>> sources around but Linux knowledgeable people will correct me, if its >>> needed there, if not we can add ifndef? >> >> Hmm. They are defined there on linux too -- must be getting included >> indirectly somehow. I do not see any reason to not just include the >> missing header directly in this case; no need to ifdef it AFAICT. > > That's great then. > >> >>> 3) DT_WHT won't be defined in <sys/dirent.h> on OpenBSD. In fact, it >>> was specifically removed. >> >> Interesting. We get the d_type field only when _BSD_SOURCE is defined >> on linux. Perhaps we should just be calling lstat(2) here? > > Theo's words, I don't know why he didn't elaborate, anyway > http://marc.info/?l=openbsd-tech&m=130085319818542&w=2 > > lstat() would be good replacement. As it is defined in Open + Free BSD > and Linux. > > http://www.freebsd.org/cgi/man.cgi?query=lstat&sektion=2&apropos=0&manpath=FreeBSD+8.2-RELEASE > http://www.openbsd.org/cgi-bin/man.cgi?query=lstat&sektion=2 > http://www.linux.com/learn/docs/man/3566-lstat2 > >>> Also, is there any interest in convert the Makefiles into CMakeLists.txt? >> >> I personally to not know CMake very well. I have used it a few times >> but not on a substantial project by any means. >> >> I do not have any flat out objections to using CMake. Eventually we >> need a configure-like stage that I was eventually going to get around to >> implementing but if that can be done using a new CMake build then that >> would be fine with me (I think). >> >> However, the test suite is based on makefiles and I do not have a >> hand in that side of things. CMake would need to be a good fit in that >> context too. >> >> Also, I think we would need to discuss if CMake can generate suitable XCode >> project files since its big advantage is the cross-platform thing. If we >> cannot use it as a cross-platform build system then I am not too sure >> what advantage is has over good old make. > > CMake is much better than anything to generate XCode project files, > Windows Vistual Studio support, Unix makefiles etc. I have hand > written some CMakeLists.txt files based on llvm/clang CMakeLists.txt > itself, but they will need to be updated by you guys when you make the > commits which add, delete, or rename files. If you follow and update > the CMakeLists.txt religiously, you can get lldb to be compiled on > almost all platforms. Of course the biggest hurdle is the support to > be added inside lldb for BSD's, Windows etc. But with CMake you can > just forget about adding tweaks for all OS to get it to compile. You > can concentrate on development and CMake takes care of compilation. > > If you are committed to using CMake, I will send across the files > after polishing it up... They aren't yet done for all the folders yet > but a major chunk is done. I really want to see lldb on OpenBSD, now > that gdb is inaccessible due to GPL v3. > > http://www.cmake.org/Wiki/CMake_FAQ#What_is_CMake.3F > > Thanks > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
