Consider avoiding to store binaries in the source code repository about opentoonz HOT 9 CLOSED

Okay, how would we accomplish this so that it will not only still build for Mac and Windows(and Linux soon), but stay stable as well? In other words what is your plan(s) to accomplish this?

from opentoonz.

Use services like travis-ci (for Linux and OS X) and appveyor (for windows) to provide continuous integration.

from opentoonz.

I'd also recommend a rewrite of history with blobs purged, while this repository is still fresh.

from opentoonz.

In case you would like to pursue that option, you will find these links most helpful:

• https://help.github.com/articles/remove-sensitive-data/
• https://help.github.com/articles/removing-files-from-a-repository-s-history/

I've also made a fork with the files mentioned above stripped away, using bfg:

for i in exe dll lib a obj o ; do bfg --delete-files \*.$i ; done

from opentoonz.

In other words what is your plan(s) to accomplish this?

I suggest to move thirdparty into a separate repository, since ideally (or hopefully in the near feature) MacOS (brew) and GNU/Linux users will not need this at all. But also for this new opentoonz-thirdparty repo I recommend not to add binaries, only source code (git is for sources in the first place). On the one hand you'd like to provide users with a comfort of prebuilt libraries, but why not then to provide a prebuilt git, cmake, compiler, binutils, libc,.. Xcode,.. OS :) So one must admit, you require some things and compared to the complexity of OpenToonz, building per hand of libtiff, libpng, libjpeg is much easier. Thus if someone decides to build OpenToonz, building of these thirdparty libraries (if at all) will be the smallest issue, I'm sure.

Since you have altered only libtiff, you would need only this in your thirdparty repo. You could put references where to get original tarballs for other libraries. Also you could put these tarballs on your site under "Download sources for thirdparty libraries" and you can still offer prebuilt ones under "Download prebuilt thirdparty libraries". They can be archived on your site, just like on sourceforge (but not in git).

Another problem with managing thirdparty libraries for you is to be sure to update them instantly once some security issue is discovered. This is one more argument to rely on that, what brew and GNU/Linux Distribution packages offer. The only important thing would be nice, if you just document that you could successfully build OpenToonz with particular versions of thirdparty libraries. And it would be even better, if you would do it from time to time, once new releases come out.

By the way, do you know, are the programmers of 64bit TIFF support still reachable? It would be great, if one could talk to the upstream to find an acceptable solution to integrate this feature in upstream. The problem that I see is the code duplication. Maybe upstream could find a nice solution for this?

So I propose:

• create opentoonz-thirdpary repository with libtiff
• document exactly the versions of used thirdparty libraries and place thirdparty libraries tarballs (sources and prebuilt ones) on the main site as downloads
• add into howto_build an additional instruction to download and unpack the required thirdparty libraries from the download section of the main site (or better: specifying direct links) (e.g., like it is already done for boost)
• rewrite history for opentoonz to get rid of thirdparty (I'm testing this now)

In case you have already negative experience with some suggestions, maybe a compromise would solve them?

from opentoonz.

@janisozaur: thanks for infos.

from opentoonz.

There's also the Github release page as a place we could store them as well. That way they can be downloaded with the source code zip files when it comes to release time.

from opentoonz.

It is not that easy. As I built the VS 2015 versions (#307) I saw, that there are local changes and in part special instructions to build the libraries. So you can't use the tars of the original packages, but it would be possible to create a repository will all the sources and a zip-archive with the binaries. I definitely agree, that the binaries should be removed from the repository.

So perhaps it would make sense to leave the sources in the tree and only remove the binaries?

from opentoonz.

Closing this - Git LFS seems to be the solution decided upon by the developers.

from opentoonz.