Cross-platform OF Download

feature requests
#1

I wasn’t sure the best place to post this as it’s half a ‘feature’ request and half just wondering what OF developers thought.

I’m working on cross-platform applications in OF. I was wondering if it’d be possible to have the option to download a “Really Fat” version of OF where all the libs and files for all platforms are merged into one (so freeimage, for example, would have all the libs for mac, win, linux). This way for those that are building cross-platform applications they can use all the same OF core stuff for each platform (don’t need 3 separate directories for each platform) and then all that is needed is a separate project file (xcode, visual studio, codeblocks, etc) file between each OS. Of course the download would be potentially (a lot) bigger, but having 80% of the same files for each platform (all the OF/libs cpp/h files) brings a lot of redundancy when having to have 3 separate folders/locations for each platform of OF. Making it so only the project file is different between each OS will make it really simple to make changes and additions without having to copy/paste various code changes from one OS to the other.

What do others think as just another optional download that people can choose?

cross compiling
#2

hey cerupcat,

for now just use: http://github.com/of/ofx-dev (and contribute to it…)

with that commit: http://github.com/of/ofx-dev/commit/a76-…-d2a5f6f55c

i added basic windows (codeblocks) support. meaning you can compile the examples (only 3 for now, you could add the rest) with codeblocks or xcode, ie windows or mac. only need to download or checkout that bundle.

beside a place to tinker with addons and such, the bundle’s goals is to be the only thing you need to download and are ready start using oF. in theorie :slight_smile:

  
[lian:~/tmp]$ git clone git@github.com:of/ofx-dev.git  
Initialized empty Git repository in /Users/lian/tmp/ofx-dev/.git/  
remote: Counting objects: 3959, done.  
remote: Compressing objects: 100% (2402/2402), done.  
remote: Total 3959 (delta 1648), reused 3547 (delta 1386)  
Receiving objects: 100% (3959/3959), 53.39 MiB | 125 KiB/s, done.  
Resolving deltas: 100% (1648/1648), done.  
Checking out files: 100% (2803/2803), done.

ON WINDOWS: you still need to install codeblocks, Quicktime and Git yourself…

#3

dear lian –

while we appreciate you putting up a git hub to mirror the OF development, this is not an official release and we have to be very careful about various versions. We are happy for you to host it, but it would be impossible for us to answer questions in the forum, for example, about issues with that link, and I would request you to be very clear about that

beside a place to tinker with addons and such, the bundle’s goals is to be the only thing you need to download and are ready start using oF. in theorie

please NO ! this is exactly what we want to avoid. this is an experimental project you are working on, fine, but this is not OF. Please don’t sell it as such.

does that make sense?

from our standpoint, maintenance, etc, it’s going to be totally unwieldy if there are different people with their own “OFs”, etc. We work very hard to answer peoples questions and make the experience of using OF easy for people. Therefore, it’s very important to us how the package works.

I think making the OF git hub is fine, experimenting on different distribution ideas, etc is fine, but presenting it as the goto source for OF is totally not OK.

thanks!
& take care,
zach

#4

i understand you, but its not clear to me why there is no infastucture for maintenance or experimental branches yet. and its a opensource community thing, so why are you angy when somebody starts to put something up we all need anyways. for me oF was kind of stuck before the newest core member. but as oF’s name noted, its open and there should be a couple of active branches to prepare releases or expermimental features. at some point oF needs to face that anyways. iam sad to see that you liky avoid that bundle.

for today, there is now real alternative to get a package with everything AND stay updated with oF’s trunk and community thoughs. of course iam selling ofx-dev as oF, and inviting everyone to contribute. not like oF’s trunk, where only 3 people have commited so far. and everyone else most drive there own road when they have ideas.

i do understand what you mean, but i think its the wrong to ignore it and just continue moving tiny steps and pissing of people.

when youre in europe i invite you to meet. on those topics easily missunderstood.

cheers,
lian

#5

please read my post above

we are not trying to avoid experimentation:

I think making the OF git hub is fine, experimenting on different distribution ideas, etc is fine

what I am concerned about is you are presenting it.

, the bundle’s goals is to be the only thing you need to download and are ready start using oF.

did you think to ask us about this?

please think about the amount of time we spend answering questions and helping people get started.

then imagine what happens if there are different distribution sources all claiming to be OF, that are not managed the same way, or by the same people. All we are asking you to do is be clear that your git hub is an experimental branch. that’s it. Is that too much to ask for ?

does that make sense? not trying to piss anyone off, trying to have fun and avoid headaches :slight_smile:

  • zach
#6

makes sense

but until oF provides a development bundle and release structure, iam going to use github.com/of/ofx-dev . because thats exactly what i need to develop apps with oF and improve oF itself. why not point all that people with ideas you can implement yet, because of core things, to a evolving ofx-dev bundle? the bundle is not made to sell something different else. in fact it even passed your concers about everyone running there own hacked oF, cause with this bundle you had a great version/diff overview. present a alternativ and iam happy contribute to that instead.

zach, iam sorry, should wrote "I for now just use: http://githu.. instead “for now”.

cheers

// edit

i invite everyone with git installed anyways to run “gitk” inside ofx-dev directory and see how easy it is to follow and track the changes, and that they are actually not many differences to what oF released. scroll to down the commits, which are not much, and see the diffs shiny presented. in such a way its not hard to maintain changes or releases by oF Core and still have a bundle that not lower quality

#7

Hi lian,

Thanks for the idea, but I have to agree with zach here and my question is really directly towards him, theo and arturo (any other core developer) you could say. I understand what you’re doing Lian, but my concern is the same one zach has. Although i’d like what you call a ‘developmental bundle’ I also want to make sure the OF core developers are the ones that make it, so that it is both official and that it is supported by the OF team and community. I could of course make the package myself and distribute it, but this wouldn’t be good and make updates hard to maintain (if not done by OF itself).

With that said, zach do you think there’s any potential for such an official download package? From what I understand, all that should be needed is to merge the 3 current files into one, as the only thing that should be different are the lib files (.so, .a., lib) and the project files (.xcode, .vcproj, etc.).

#8

Hey,

[quote author=“cerupcat”]
What do others think as just another optional download that people can choose?[/quote]

I will also welcome an optional download for a cross-platform OF!!!
For me there are some difficulties to use the same OF-projects on windows (CB) and linux (CB) at the same time.
It could be perfect, if I can use the next OF006 easy on both platforms with only two different *.cbp-files.

  • Seven
#9

I hate to bump my own post, but since there was interest in this before and now that 006 is out, I was wondering if we could get some possible thoughts towards an implementation of a optional single download package for all platforms.

#10

yes, we’d love to do this. Actually, we’re heading in that direction, since it will help make releasing OF faster. You may notice simple changes, like OSX compiling to the bin folder (which we made thinking of heading towards the request), but it may take a little while longer to get everything exactly the same. If you’d like to try w/ 0.06 and point out any more needed steps, we’d be happy to hear.

take care!!
zach

#11

That sounds good zach and great to hear :smiley:

#12

Now that i’m in the cross-platform domain as well (mac + windows), I too am very keen on this so I can avoid duplicating my project src+data (and addons) in two separate ofw folders.

I’ve had a look at the mac + windows ofx folders and my ideal setup would be (and I think Seth is referring to the same):

OF-ROOT
addons
apps - app folders contain both codeblocks and xcode projects (details below)
libs - contains windows and mac libs (and linux)
other
scripts

and in each app folder (which wants to be cross platform) :

myproject.cbp
myproject.depend
myproject.layout

myproject.xcodeproj
openframeworks-Info.plist

obj/ - codeblocks intermediary files
build/ - xcode intermediary files
bin/ - data and binaries for both mac and windows
src/ - shared source

There probably is a cleaner way to divide the interior of each project folder, but for the time being that’ll keep me happy.

The problem is the libs folder:
fmodex - versions are different, all the header file contents are different.
freeimage - mac folder is organized (include + lib) whereas windows is not (all in root)
freetype - versions are different, all the header file contents are different, and different files in different folders.
glu - no glu on mac, i guess cos its already included on mac.
poco - mac has includes in ‘include’ folder and lib in ‘lib’ folder, windows has includes in ‘includes’ folder and lib in ‘libs’ folder
quicktime - again no quicktime on mac, probably cos its already on mac
rtAudio - folder structure completely different
videoinput - don’t exist on mac

I’m not sure how different the headers and source is for the above libraries for the same versions (I guess they shouldn’t be different, thats the whole point of having cross platform libraries, right!?). So theoretically they could be merged so that there is only one set of headers/source in each lib folder, with just different .dll, .lib, .a for windows and mac (and linux)?

Dunno what people think about this?

Of course changing the folder structures in the libs to unify across platforms will break backwards compatibility with project files :S

#13

I guess you could have your app folder like this (which might be better):

  
  
Apps  
   My Projects  
      Project 1  
         windows  
            obj/ - codeblocks intermediary files  
            myproject.cbp  
            myproject.depend  
            myproject.layout  
         linux  
             <whatever linux files are>  
         mac  
             build/ - xcode intermediary files  
             myproject.xcodeproj  
             openframeworks-Info.plist  
         bin/ - data and binaries for mac, windows and linux  
         src/ - shared source

this is just an idea and I’m open to suggestions, I just wanna share my src and data between all platforms without having to sync and update between them!

#14

actually Memo, Linux codeblocks files are identical to that on Windows…and you can even open them with codeblocks on Windows without problems, since a .cbp is just an XML file (only difference is the linking info etc).

I’d be curious to see if someone ever got codeblocks running on OSX?

#15

Hey pierre, that sounds interesting. Do you mean the same cbp could be used on linux and windows? Cos that would be ace (especially if it worked on mac too). But would the linked lib paths not differ? I.e. the libs for windows are in one folder, libs for iinux in another…

#16

Yes the linking details differ, but what I mean is that it’s not too much trouble to open a Linux .cbp in Windows and fix the linking/include differences…although sometimes I just create a similar workspace from scratch and then copy stuff across. It’s not cross-compiling in the slightest, but it’s much easier to transition from Linux to Windows via codeblocks than it is via Visual Studio…and I imagine the same would apply to Mac as well, which is why I’m curious to see if anyone has tried it. I’ve got a mac mini, I guess I should try it myself :slight_smile:

#17

Since the linkage are different, I don’t think that’s really ideal.

The concept is to have one cross-platform download that doesn’t require changing things around (like how things are now, but combined). Separating the win/lin codeblocks would probably have to be a must in order to avoid the link issues.