search

EricssonResearch / cerbero

OpenWebRTC cerbero fork
GNU Lesser General Public License v2.1
19 stars 58 forks source link

osx-x86-64 fails after version change #23

Open ikonst opened 9 years ago

ikonst commented 9 years ago

With each version, we change the osx-x86-64 prefix path, e.g. to /Library/Frameworks/OpenWebRTC.framework/Versions/0.3.

However, this breaks incremental builds, since .cache files will still indicate components are built. For example, if gettext is "built" (but still resides in 0.2), building "glib" will fail since it's looking for gettext in 0.3.

Is there a way we can make it more user-friendly?

superdump commented 9 years ago

All the libs built for OS X are not easily movable because for reason they have to have their path written into the file itself. There is a script to migrate them but honestly I wouldn't trust it and it would be a job in itself. to write something using that script to migrate all the build results.

It is so much easier to do a wipe --build-tools and then rm -rf /Library/Frameworks/OpenWebRTC.framework and then start from scratch. Leave the build going overnight or something.

NOTE: Before doing the wipe, you'll want to copy out any changes and work you've been doing in the cerbero sources though.

I completely agree that it is awkward but I at least partially blame OS X library file format. I've personally just wiped and rebuilt while doing other things.

This isn't going to happen every week but I suppose it may happen for many releases until the API calms down. It depends if we bump the API version for backwards compatible API changes. I'm inclined to say we shouldn't if an app that did work would still work but with the newer version they have the opportunity to add more features. So it's possible the next version would be 0.4 but the API version would be 0.3 still. Hmm, but then when the next version comes adding more API it would need to have been bumped for 0.5 to know that 0.4 apps should still work unless you know you're still using 0.3 API. Not so simple.

Suggestions welcome but I think it's going to be painful to make it robust.

superdump commented 9 years ago

@sdroege how does GStreamer manage this? Never change from 1.0 because everything has to be backwards compatible until 2.x?

ikonst commented 9 years ago

I don't mind the need to rebuild as much.

My problem is the fact that there's no dependency on the config file basically. If the config files change, it should invalidate the built recipes.

sdroege commented 9 years ago

@superdump Yes, we stay at 1.0 until 2.0. Which is somewhat consistent with the naming of the libraries everywhere, and follows the API version.