@Etienne That is good news indeed. I was getting nowhere with a commit (I must have been doing something wrong in the process up to then or it is because I didnt fork directly but added a remote and fetch) and had to put it on the backburner because I have been booked for a freelance job.
So, sure if you already have all my commits on top of yours there's no point in me doing the same. I can fork or pull from you then. If you don't mind, can you include my README.markdown for GitHub? I think having some more explanation about building in there helps new devs such as myself. Throw the legal bit out if clashes with QS' existing paradigm. @Paul Kohut "Have you gotten a clean compile with LLVM/Clang?" IIRC, not at first. I had to work quite a few changes but Clang's error messages are superior to GCC and also can show you the exact location the error is in the line which was helpful. We are still at around 125 warnings though. Most are still deprecation stuff and stuff from the NTViewLocalizer which would confuse any compiler. I dont't think we can get rid of those (other than trying Clang's awesome ability to disable/enable a specific warning on a per file and per-line basis). About your build errors: Keep in mind that you need to make sure that each xcconfig file is used for the correct build configuration (you know the little dropdown at the lower right of the build settings dialog). Sometimes Xcode forgets what was asigned to what build configuration especially if you duplicate a configuration or make a new one. I could imagine that's where your build errors are coming from. If not there are two settings that seem to influence the build differently than GCC. I think one is the Always Search User Paths. The other I can't remember but it has to do with where the pre-compiled headers are stored for the frameworks leading to Clang thinking there is code duplication (lotsa "... already defined" errors). I think I put a few comments regarding the Clang build stuff inside the Developer.xcconfig on my repo. I can't take a look right now because I am at a work computer provided by someone else. @ Rob I guess the preferred way of posting issues may now be over at github.com/tiennou/blacktree-alchemy under the Issues tab. Or we just continue the issues tracker over at Google Code. It's really Etienne's decision as Etiennie's repo now will be the main one once again. Personally I wouldn't mind continuing at GC but I wouldn't underestimate having the code and the issue tracker in one place. Cheers, André PS. As I am working the freelance job I may be unable to respond properly or look into stuff for days even. We'll see how it goes. On 9 Nov., 11:15, Etienne Samson <[email protected]> wrote: > Hi André ! > > I have some good news for you. I already did the conversion (moved > your commits on top of my branch), so if it's good for you, I can pull > all your changes to blacktree-alchemy, then you'll just have to fork. > > I also looked a little at the state of the Airport Module, and the > situation is dire. We're using Private APIs for this, and there were > heavily changed on SL (Look up Apple80211.h), and now the one we have > now returns an error, and the Airport Module just call exit() if it > fails... > > Etienne > > Le 7 nov. 2009 à 23:46, andreb a écrit : > > > > > > > If you just want to try the GitHub version out there's no need to > > install Xcode just for this. > > As elspub says I have also posted a downloadable binary. > > > I am currently working on integrating my GitHub repo with the soon-to- > > be official GitHub repo Etienne set up. > > As our commit SHAs differ I will need to go through each on and lay on > > hand on the stuff that doesn't merge cleanly > > (which is almost all commits since I haven't really added much - just > > changes). > > > I should probably mention this fact on my repo's tagline before we see > > forks from my one - which really isn't good at this point in time. > > > And, yeah, it feels good to see someone reporting improvements. :) > > > Etienne brought me onto really using Git. It's such an improvement > > using it and GitHub for collaboration. > > I think Quicksilver and the way multiple devs working over the net is > > the perfect type of project for Git and GitHub. > > > Another thing I am really enjoying is LLVM/Clang. > > Apple and their contributors have done such an amazing with this new > > compiler it almost feels unreal. > > > André
