Binaries and building

[Xender]

Hi.

Including compiled binaries in Git repo is in general a very bad idea.

• Git tracks a history of all files at every commit. Once you commit a binary into the history, it stays there. Retconning a commit means rewriting all of it's child commits (as in git commits are immutable and has a SHA1 of the parent permanently stored in their data.)
  • That unnecessary blows size of the repo with useless files (old compiled versions, which have no historical value as opposed to source code). As cloning a git repo clones whole history, this is a real problem (as opposed to e.g. SVN, where one fetches a single revision at a time.)

If you look for an easy way of distributing compiled versions, please look at GitHub's "Releases" feature. They allow to include binary files to downloads, without baking them into repo's history.

There are also no instructions for building from source. Nor there is a Makefile (as invoking make is fairly straightforward as long as Makefile doesn't do anything unexpected, providing a Makefile can be considered as an alternative to readme section about building instructions).

• This is crucial, because Open Source is not about "you have binaries, but you can also take look at the source code". It's about being able to actually do something meaningful with the source code - not only looking at it, but also building an application from it and modifying it. The source it the crucial part, binaries are an extra - not the other way around.

Also, does it run only on Windows with GNU tools installed, or is there a way to build a Windows+Visual Studio, GNU/Linux and Mac versions?

[PsichiX]

Thanks for your ideas - for now i've done release feature, next thing that i will do is this building from source description. For now this can be only compiled with Code::Blocks on windows, in future i will provide build scripts for unix and i will add another IDEs to work with Zasuvka.

[poxip]

@PsichiX, use cb2make to generate Makefile from C::B project, example Makefile (main makefile):

cb2make cbproj.cbp -o Makefile.cb
make -f Makefile.cb

Just example, but i think, cmake will be better instead of Makefile.

[Xender]

Okay.

I see that project has both C++ and C# parts. I have no experience with C# on other OS-es, I only know that there is Mono...

As for .cbps, it looks like there's also tool called cbp2mak.

[PsichiX]

ok, so in one of the next versions i will provide makefiles for C++ and C# projects and executing them from makesdk.sh script (i have now all needed tools, thanks guys!) :)

[Xender]

http://www.nooooooooooooooo.com/

Speaking seriously, it looks like it would be better the other way - to put all the things that makesdk.sh script does as .PHONY "install" target in Makefile.

That one one could do good old "make install"

And there are some platform-specific *.dll globs in there (as well as such files for third-party libraries in repo, but I hope that is subject to being cleaned up?). It would be best if those would be handled in a generic way, because even when ported and done cross-platform, having separate if-else's for each platform would be pretty messy. I think that just whole contents of the folder should be copied. It's a matter of having the project hierarchy clean.

[PsichiX]

@Xender: what do you think about making platform-specific submodules for "requerements" folder to keep third-party libraries separated from pure code?

[poxip]

@PsychiX: do not include prebuilt libraries to source.

[Xender]

That's certainly better, but why not just include the binary libraries only in Windows releases? I'd go like this:

• Document build process, possibly with some refinements (Makefile) in the process.
• List dependencies in Readme.

As far as I see, Linux people usually compile non-distro-packaged things from source (unless it's Firefox, sth written in Haskell, or similar building PITA :D), so the main need for releases are Windows compiled versions. So for them you can:

• Package regular binary releases with 3rd party dependencies included.
• For source builds on Windows, prepare special deps-only GH release[s] to save people's time on downloading them from multiple sources or compiling them.
  • Note that in Readme too, otherwise it won't make sense.

As releases are based on particular commits anyway, using either submodule or a separate branch for Windows binary deps could even be necessary for that (I don't know to what degree). Should it be submodule or a branch - hmm...

• Submodule has to be hosted git repo on it's own anyway. Separate "Ptakopysk-binary-Windows-dependencies" repo would do, but it looks a bit weird.
• Is it possible to include only files from submodule in a GH release?
• As for branch for binaries - it would be downloaded when someone does git fetch, but it's not needed at all for Linux people and maybe-needed for Windows people... So that could be a waste.
  • On the other hand, the blobs are already in the master branch history. So it's possible to:
  • Let them just be, despite them being rather useless (will anyone search repo history for deleted DLLs?)
  • Rewrite history with rebase or filter-branch to delete them and force-push rewritten history. PITA for everyone who has cloned repo and wants to pull new changes (man git-rebase, "RECOVERING FROM UPSTREAM REBASE" section)
  • Exploit the fact and just go with separate branch for binary deps. Git will reuse blob objects (as any objects). Hope that there won't be many updates of those binaries in separate branch (fetch overhead, as above).

[PsichiX]

ok, so next weekend i will start to cleanup repo from binaries and prepare it to work with another platforms based on your advices, guys - at first i need to fix bugs and enhance IDE side to work more simple during making tutorials :)