[scratt]

Afternoon!

I am trying to get some OpenSource things to compile..

I have created the base frameworks for these libraries, and in them are the include (.h) files that I am tring to reference from the project.

The name and path of one for example is dir/dirc/fred.h. This is a hangover from an old include file.

In another case though the file is just referenced by it's name fred.h

Neither case works.

In my framework I have the fred.h include file.

But it still does not find it.

I can see how (perhaps) for the first example, but not the second one.

The frameworks are properly highligted to be included in the final output as well as the build.

I have tried all the obvious stuff like cleaning and building and including all the include files as another Xcode Build phase..

If I copy another version of the fred.h file into the source are of Xcode it resolves the issue.. Exactly the same include file that is in the frameworks. Anyone know why?

[thuh Freak]

its been a little while since i used Xcode... let's see what i remember.

frameworks are pretty dumb sometimes. thats a link to apple's page documenting their structure. from c/c++/objc, when you do:
#include <framworkName/file.h>

apple's version of gcc will look for the framework. it prefixes the framework's path to 'frameworkName'. next, it inserts 'Current/Headers' between 'frameworkName' and '/file.h'. So, in code, if you do:
#include <frameworkName/folder/folder/file.h>

it'll look at /../Frameworks/frameWorkName/Current/Headers/folder/folder/file.h. In code, if they sometimes use folders prefixes to the file, and sometimes don't, the code should really be fixed. but, you can add the full path right before the file to the list of includes. something like: -I/path/to/frameworkName/Current/Headers/folder/folder/. if you put that switch into the custom CFLAGS/CXXFLAGS/OBJCFLAGS, it should find the file if its included like this:
#include <file.h>

what OSS are you looking at installing? idk if you're familair with fink, darwinports or some of the other pre-packaging services, but its possible that the programs ur looking for already have a nice+easy installation for mac. if you don't find them, its probably easier to avoid using frameworks for OSS software, aside from apple's where necessary.

[PKIDelirium]

I'm having an XCode problem myself...

The program is there, I installed it.

BUT.

It's not listed in Applications!

The only way to access it is to search for it, and search says it's in Applications. But it's not there when I look!

[scratt]

Originally Posted by PKIDelirium I'm having an XCode problem myself... The program is there, I installed it. BUT. It's not listed in Applications! The only way to access it is to search for it, and search says it's in Applications. But it's not there when I look!

Restart the Finder, and Xcode.

I have this happen a couple of times this week (and not while using Xcode) and am beginning to wonder if it's a Finder bug.. The only way I could get a file that an ls in bash would show when in the very same directory in Finder it would not, was to relaunch the Finder!

[scratt]

Originally Posted by thuh Freak its been a little while since i used Xcode... let's see what i remember. frameworks are pretty dumb sometimes. thats a link to apple's page documenting their structure. from c/c++/objc, when you do: #include <framworkName/file.h> apple's version of gcc will look for the framework. it prefixes the framework's path to 'frameworkName'. next, it inserts 'Current/Headers' between 'frameworkName' and '/file.h'. So, in code, if you do: #include <frameworkName/folder/folder/file.h> it'll look at /../Frameworks/frameWorkName/Current/Headers/folder/folder/file.h. In code, if they sometimes use folders prefixes to the file, and sometimes don't, the code should really be fixed. but, you can add the full path right before the file to the list of includes. something like: -I/path/to/frameworkName/Current/Headers/folder/folder/. if you put that switch into the custom CFLAGS/CXXFLAGS/OBJCFLAGS, it should find the file if its included like this: #include <file.h> what OSS are you looking at installing? idk if you're familair with fink, darwinports or some of the other pre-packaging services, but its possible that the programs ur looking for already have a nice+easy installation for mac. if you don't find them, its probably easier to avoid using frameworks for OSS software, aside from apple's where necessary.

Thanks again dude...

I have managed to move past that problem tonight.. Not quite sure what happened.. But I suspect an Xcode 'feature'

I want to work with Frameworks to be honest ant get rid of all my libs so I can produce a buildable stand alone product for the Mac. Even when I use fink stuff I do try to get hold of the source and make sure I can compile it myself so that further down the road I am not dependant on a library that doesn't get updated, or developes an issue, or dissapears etc. etc.

Right now I am working using OpenSceneGraph and VTerrain along with their dependancies and a host of other add ons to produce my own Simulation Engine.

I keep source backups of the entire developement library, but work from Frameworks for speed.

When I stop my proof of concept work and stabilise my Simulation Engine I will then lock that off and build the final simulation project on top of it...

I have no idea how long this project will take and the chances are we will be Intel based and a couple of generations of graphic card and hardware down the line... So I really need to keep this as modular and portable within the Apple OS timeline as possible..

Thanks for your input though on that one...

[PKIDelirium]

Originally Posted by scratt Restart the Finder, and Xcode. I have this happen a couple of times this week (and not while using Xcode) and am beginning to wonder if it's a Finder bug.. The only way I could get a file that an ls in bash would show when in the very same directory in Finder it would not, was to relaunch the Finder!

No dice, still isn't there.

[Brad]

Are you talking about the Xcode.app itself?

It's not in /Applications.
It's in /Developer/Applications.

[scratt]

Well spotted Brad. I wrongly assumed he meant an application not Xcode.

Yeah.. What Brad said!

*grumbles smarty pants*

[PKIDelirium]

Originally Posted by Brad Are you talking about the Xcode.app itself? It's not in /Applications. It's in /Developer/Applications.

Doh!

*Feels stupid* thanks!

[thuh Freak]

hmm. u might be putting yourself in a difficult position. if the frameworks are entirely your creation, and not supported upstream, then u are their maintainer. it wouldn't be totally stand alone unless u statically link all the external dependancies. thats not necessarily a terrible alternative. i used to do that with some *nix libraries, cuz the lib i was linking against kept changing its interface every point release or so.

[scratt]

Originally Posted by thuh Freak hmm. u might be putting yourself in a difficult position. if the frameworks are entirely your creation, and not supported upstream, then u are their maintainer. it wouldn't be totally stand alone unless u statically link all the external dependancies. thats not necessarily a terrible alternative. i used to do that with some *nix libraries, cuz the lib i was linking against kept changing its interface every point release or so.

I'm intrigued.. Can you elaborate...

My thinking has always been that if I have standards compliant source then in theory anything is possible. Certainly I should be able to maintain it and keep it running on a stable developement platform... But your comments have me concerned now...

[thuh Freak]

in theory, communism works. in theory. -hjs

well, lets pose a hypothetical: lets say we're at version 1.0.0. you package it up into a framework. two weeks later, upstream they make 1.1.0, which fixes some major issues from 1.0.0. users notice these issues well before you, because well, it happens sometimes. unfortunately for the users, you aren't available to update the framework in the time-frame they like. end-users, who have no clue about building the framework for themselves, now look at other products; or become annoyed at the crappy performance of the program with the lingering bug.

{i'm thinking of this as a product your packaging up so others, not just yourself, would be using it. perhaps a bad assumption. if you don't plan to have users, this is all a non-issue.}

statically linking (ie, resolving all external dependancies at compile time; in other words, only linking .o files and .a libraries, no frameworks, no .dylib's and no .so's) would solve this problem. but it presents another one. you are forced to recompile the full program if any of the dependancies are updated (ie, when 1.1.0 comes out). link time is also greater. the program itself will be physically larger on disk. in theory, the program would start up faster, but i dont think it makes a huge difference in practice. if your end result is several programs, which perchance would have shared libraries/frameworks with each other, then you'll be essentially wasting (a minute amount of) file space.

as you'll have to distribute the frameworks with the program (which is mandatory if you go with the framework-idea), it wouldn't really resolve the "no external dependancies" plan. the only way to avoid external dependancies is to (a) lobby apple to include your libraries/frameworks as part of the base OS, or (b) statically link.

making the shit into frameworks isn't necessarily a bad idea. but it means that you have to be a bit more active about updating the framework when its underlying code is updated. i'm not saying you shouldn't do it, but i think it'd be a lot easier to work with the libraries as they are created by the default source installation. distributing and using those isn't that hard, imo.

[scratt]

Get your point... Except the majority of the stuff I am using as either Dynamic libraries or Frameworks is not something that an end user will be able to install very easilly... Nor want to try...

I also doubt Apple would include most of these in their OS.

Case in point I am using OpenSceneGraph and also VTerrain. OSG I could see in the dim distant future becoming an industry standard, certainly in open source based operating systems... That would be a bonus to everyone IMHO.

VTerrain and the host of supporting libraries for that I cannot see being adopted. Perhaps some of the cross platform windowing technology that it uses, but then I am not using that part of the code.

The other problem is I am taking a version of each of these systems and then modding them in certain ways, so I will be breaking from the path of developement that the libraries are on, so to speak. So I will still want to produce libraries, or frameworks or binary in a final distribution, but they will be 'scratt' flavours of those libraries, frameworks or binaries, and only related to the original source... eventually.

I want to stay with source and frameworks right up until the end of the project so that I keep the whole project modular, and when Open Scene Graph get's updated I still have the option to take their modifications onboard also..

I am not in a rush with this project, and as I said, have no idea what final platform, OS or form the project will be released so I am trying to keep the developement as flexible as possible...

I am also relatively new to developing on an OS like OS X, so may not be making all the right decisions from the outset, but that's part of the fun and the learning process.

For that frameworks and libraries, which I control the source for seems the best to me right now...

That is not to say when this goes Alpha or Beta it will not be put out as one big standalone binary... Perhaps I am msitaken, but keeping control of the source and working with frameworks, I thought, meant that on pretty much any system I can generate an independant piece of code that will run on any other system.

Thanks for your feedback on this. It's a usefull discussion. As I said this is all based on my limited experience so far of working in the OS X environment so do please let me know if I am missing something...

[Enki]

Originally Posted by scratt Thanks again dude... I have managed to move past that problem tonight.. Not quite sure what happened.. But I suspect an Xcode 'feature' I want to work with Frameworks to be honest ant get rid of all my libs so I can produce a buildable stand alone product for the Mac. Even when I use fink stuff I do try to get hold of the source and make sure I can compile it myself so that further down the road I am not dependant on a library that doesn't get updated, or developes an issue, or dissapears etc. etc. Right now I am working using OpenSceneGraph and VTerrain along with their dependancies and a host of other add ons to produce my own Simulation Engine. I keep source backups of the entire developement library, but work from Frameworks for speed. When I stop my proof of concept work and stabilise my Simulation Engine I will then lock that off and build the final simulation project on top of it... I have no idea how long this project will take and the chances are we will be Intel based and a couple of generations of graphic card and hardware down the line... So I really need to keep this as modular and portable within the Apple OS timeline as possible.. Thanks for your input though on that one...

Hitch a ride with these guys:
Delta3d . It has some long term Uncle Sam funding to generate a royalty free engine with the goal of eventually being better than Vega and stay close to the FPS eye candy levels. While I'm not currently involved, the core team has some good dudes on payroll and wants to work with others in the full open source arena. They need a kick in the pants though to get the Linux builds over the top into OS X compatibility, it hasn't been a priority so far even though they like the idea.

You will get a lot farther with a group like this than going lone wolf.

OBTW: they are working on top of OSG, ODE, OpenAL and CAL too.

[scratt]

Originally Posted by Enki Hitch a ride with these guys: Delta3d . It has some long term Uncle Sam funding to generate a royalty free engine with the goal of eventually being better than Vega and stay close to the FPS eye candy levels. While I'm not currently involved, the core team has some good dudes on payroll and wants to work with others in the full open source arena. They need a kick in the pants though to get the Linux builds over the top into OS X compatibility, it hasn't been a priority so far even though they like the idea. You will get a lot farther with a group like this than going lone wolf. OBTW: they are working on top of OSG, ODE, OpenAL and CAL too.

Thanks for the heads up on that. I had a look but the lack of OS X progress put me off. I also thought it looked a bit too much like a Torque engine...

I also (to be honest) had to think about the fact that I could never publically (with my political leanings so openly exposed here) publically endorse such a project!!

I did not know it was build on top of OSG. Very Interesting.

I am currently running OSG with the OSG AL module and Cal as well. So the engine setup is very similar to my base 3D engine. Christ I remember writing my own right down to scan conversion on a C-64 years ago.. In the end for maximum speed we actually had the code for drawing horizontal lines in polygons hard coded and picked a point to jump into it to draw each line on screen! So glad the Open Source community have done such a good job on this, and graphics hardware has grown up so much!

By grabbing stuff like this we save months, if not years of developement time.

My project needs to bring in some serious terrain and planet modelling for what I want to achieve which is why I have been looking so hard at the OSGTerrain modules, as well as VTerrain and Demeter.

I have found the guys supporting VTerrain, both the OS X guy and the creator to be very very approachable, and totally helpful so far.

But based on your comments I will take another look.. DO bear in mind it's planet wide landscapes which I need to be able to do though, and the ability to descend onto them from outer-space a'la Blue Marble....