Install target does not install the main binary about abaddon HOT 9 OPEN

correct there is no install target defined. i dont really know how it works but im open to a PR or maybe i will look into it at some point in the future

from abaddon.

The current state is somewhat problematic, IMO, since it is not just that target is completely absent (which is kinda fine, at least a user will get an error or sees nothing being installed): it is present, but installs some random stuff without installing the main thing :)
So an impression may be that the app is broken, but it is not the case really.

from abaddon.

@ouwou Took a bit of time to sort this out, but I have it running now on a PowerMac in 10.6 ppc :)
Not sure if a voice chat will work, but at least it is actually running. Astonishing!

from abaddon.

voice chat should work :^)
im guessing the "random stuff" you refer to is maybe because of subprojects? im not sure how all the install stuff works. i could try and figure out how to write an install target but might take some fiddling cuz of resources. perhaps i should finally figure out glib's resource management since i think that embeds most of it in the executable and would simplify stuff a lot

from abaddon.

im guessing the "random stuff" you refer to is maybe because of subprojects?

Yes. IMO, it should either install everything which is chosen via configure args (and obviously, the main binary), or install nothing (leaving it to a user). The second choice is not great, since it may not be obvious, what exactly should be installed and where.
But with existing setup what I got initially was installation of side components without the main binary. So it looked like it installed successfully, but it was completely unusable.

For Macports, I used externally installed dependencies, so that we do not need to fetch submodules and possibly build duplicate libraries. And we handle installation manually via destroot phase in portfile.

But it will be nice to have it fixed for everyone.

from abaddon.

And indeed, main CMakeLists have nothing about installing of what they build

The thing with packaging/installing is, that I originally wanted it to be all statically packaged and I made a sort-of proof of concept for a nonstatic .app build on #207. I currently still use that Abaddon.app approach but problem being is that I couldn't get static builds working at all and left it as is.

from abaddon.

@TheMorc Could you share contents of the bundle with paths? I can try reproducing it locally.
(I am not planning to copy duplicate libs inside the bundle, but we can simply symlink those to mimic what the app expects.)

from abaddon.

@TheMorc In fact Macports has a portgroup which implements app packaging, I can see if that gonna work.

from abaddon.

@barracuda156 nothing is really that much different in the app bundle from that zipped one in the other PR, the executable doesn't really need symlinks or any lib gymnastics to get working. I just wanted it to have them packed there for the simplicity that you could download a build without building it yourself.

Abaddon.app:
	Contents:
		Info.plist
		MacOS:
			abaddon
		Resources:
			Abaddon.icns
			css
			fonts
			res

from abaddon.