Install target does not install the main binary
Opened this issue · 9 comments
There is something very wrong with how install target is set up currently.
I have written a port for abaddon which uses default settings, and here is what gets installed:
---> Installing abaddon @0.2.1_0
Executing: cd "/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_net_abaddon/abaddon/work/destroot" && /usr/bin/tar -cvf - . | /opt/local/bin/lbzip2 -c9 > /opt/local/var/macports/software/abaddon/abaddon-0.2.1_0.darwin_23.arm64.tbz2
a .
a ./+STATE
a ./+PORTFILE
a ./+CONTENTS
a ./+DESC
a ./+COMMENT
a ./opt
a ./opt/local
a ./opt/local/include
a ./opt/local/lib
a ./opt/local/lib/pkgconfig
a ./opt/local/lib/cmake
a ./opt/local/lib/libixwebsocket.a
a ./opt/local/lib/libkeychain.a
a ./opt/local/lib/cmake/ixwebsocket
a ./opt/local/lib/cmake/ixwebsocket/ixwebsocket-targets.cmake
a ./opt/local/lib/cmake/ixwebsocket/ixwebsocket-config.cmake
a ./opt/local/lib/cmake/ixwebsocket/ixwebsocket-targets-macports.cmake
a ./opt/local/lib/pkgconfig/ixwebsocket.pc
a ./opt/local/include/keychain
a ./opt/local/include/ixwebsocket
a ./opt/local/include/ixwebsocket/IXWebSocketMessage.h
a ./opt/local/include/ixwebsocket/IXSocketTLSOptions.h
a ./opt/local/include/ixwebsocket/IXWebSocketCloseInfo.h
a ./opt/local/include/ixwebsocket/IXBase64.h
a ./opt/local/include/ixwebsocket/IXHttpServer.h
a ./opt/local/include/ixwebsocket/IXWebSocketHandshake.h
a ./opt/local/include/ixwebsocket/IXWebSocketInitResult.h
a ./opt/local/include/ixwebsocket/IXStrCaseCompare.h
a ./opt/local/include/ixwebsocket/IXWebSocketPerMessageDeflateOptions.h
a ./opt/local/include/ixwebsocket/IXWebSocketPerMessageDeflate.h
a ./opt/local/include/ixwebsocket/IXHttp.h
a ./opt/local/include/ixwebsocket/IXWebSocketServer.h
a ./opt/local/include/ixwebsocket/IXUuid.h
a ./opt/local/include/ixwebsocket/IXUtf8Validator.h
a ./opt/local/include/ixwebsocket/IXProgressCallback.h
a ./opt/local/include/ixwebsocket/IXGzipCodec.h
a ./opt/local/include/ixwebsocket/IXUserAgent.h
a ./opt/local/include/ixwebsocket/IXSelectInterruptEvent.h
a ./opt/local/include/ixwebsocket/IXWebSocketVersion.h
a ./opt/local/include/ixwebsocket/IXCancellationRequest.h
a ./opt/local/include/ixwebsocket/IXSocketFactory.h
a ./opt/local/include/ixwebsocket/IXWebSocketProxyServer.h
a ./opt/local/include/ixwebsocket/IXDNSLookup.h
a ./opt/local/include/ixwebsocket/IXExponentialBackoff.h
a ./opt/local/include/ixwebsocket/IXWebSocketSendData.h
a ./opt/local/include/ixwebsocket/IXSocketServer.h
a ./opt/local/include/ixwebsocket/IXWebSocketOpenInfo.h
a ./opt/local/include/ixwebsocket/IXWebSocketHandshakeKeyGen.h
a ./opt/local/include/ixwebsocket/IXWebSocketTransport.h
a ./opt/local/include/ixwebsocket/IXWebSocketCloseConstants.h
a ./opt/local/include/ixwebsocket/IXWebSocketMessageType.h
a ./opt/local/include/ixwebsocket/IXWebSocketPerMessageDeflateCodec.h
a ./opt/local/include/ixwebsocket/IXGetFreePort.h
a ./opt/local/include/ixwebsocket/IXWebSocketErrorInfo.h
a ./opt/local/include/ixwebsocket/IXSelectInterrupt.h
a ./opt/local/include/ixwebsocket/IXWebSocketHttpHeaders.h
a ./opt/local/include/ixwebsocket/IXSetThreadName.h
a ./opt/local/include/ixwebsocket/IXSocket.h
a ./opt/local/include/ixwebsocket/IXWebSocket.h
a ./opt/local/include/ixwebsocket/IXBench.h
a ./opt/local/include/ixwebsocket/IXConnectionState.h
a ./opt/local/include/ixwebsocket/IXUdpSocket.h
a ./opt/local/include/ixwebsocket/IXSelectInterruptFactory.h
a ./opt/local/include/ixwebsocket/IXUniquePtr.h
a ./opt/local/include/ixwebsocket/IXSelectInterruptPipe.h
a ./opt/local/include/ixwebsocket/IXSocketOpenSSL.h
a ./opt/local/include/ixwebsocket/IXNetSystem.h
a ./opt/local/include/ixwebsocket/IXHttpClient.h
a ./opt/local/include/ixwebsocket/IXWebSocketSendInfo.h
a ./opt/local/include/ixwebsocket/IXSocketConnect.h
a ./opt/local/include/ixwebsocket/IXUrlParser.h
a ./opt/local/include/keychain/keychain.h
---> Activating abaddon @0.2.1_0
And indeed, main CMakeLists have nothing about installing of what they build.
Notice, the build itself is fine, I get abaddon in CMake build directory and it can be launched normally. But it does not get installed.
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
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.
@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!
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
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.
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.
@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.)
@TheMorc In fact Macports has a portgroup which implements app packaging, I can see if that gonna work.
@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