installers #59
installers #59
Conversation
|
|
And the same probably applies to Windows: It doesn't make much sense to produce an installer for Windows, unless it is a MSI-Style "Merge-Package" ( |
Hm, ok. A new central scripts repo is a good idea. This has to go to Launchpad as well then as a build dependency.
Right, there's no purpose here. This should go to the MGV main repo. There's a chance though, that we want to install the GitWrap and Heaven as standalone libraries. Maybe we would be better off with Homebrew ( http://brew.sh ) here. This works similar to APT.
Uhm, right. But MSM (the merge modules mechanism) and NSIS don't like each other. I think there's a better way to get it right. It is mostly, because NSIS makes the deployment more easy by probably just adding another build target, instead of including MSI. Or am I wrong?
Basically libgit2 doesn't build like we integrate it. There's a problem including the |
That's plain stupid then :)
In that case, yes - this was actually, what I was trying to say. However, I indeed think that anyone building an application for Mac OS X will know exactly, if frameworks or flat libraries are needed. For such a use case, it might be best to provide a simple and easy to run build experience - Since I guess any decent developer will probably do it by themselves.
Once you got your head wrapped around the MSI Technology (and the WiX tools), it's quite easy and straight forward. And so much more powerful than all the *nix alternatives... :) Really, NSIS is more pain in the longer run. The CMake support isn't very good either (IMHO).
Surprise. Surprise. Who would have guessed? The way I did it, was a quirk, a kludge, a real nasty way to get rid of the ignorance to my improvements. But that's past. It should be possible to do it better nowadays. Better means: Build upon the
Oh my dear... You're building for that ancient monster? And even using a so much diversified tool chain? Seriously, nobody uses Wixp anymore! |
Let's leave the past behind then and switch the submodule to the original lg2 repo. That's the best we can do and it will ease the building/testing process.
Funny game! I'm not using Windows at all and be happy :). It runs in a VM only to build for this OS! The question is: Does it work with that toolchain on Win7/8? If so, MGV should completely build (by copying the library binaries and headers manually to the MGV build dir). Would be great, if we could provide a windows binary as well. If I read right, we can provide a WiX (oh, what a name 😆) installer from CMake, right? Using that on windows is the better alternative, yes. |
The repository-copy is just a safety-net. Keep it, you should :)
Well... Yes and no. Windows really is the path to the dark side... Once you're there, you're doomed to stick with it. Should read like: If you provide it once, you'll probably have to support it - and you know how people are: You give them a helping hand and they'll come back tomorrow and grab your whole arm... |
|
Oh, and yes: you're right a) WiX is indeed an interesting name for a "program that adds something to another person's intimidate data locations" and b) seems like CMake supports this :) |
Yeah, that's actually a good alternative :). Btw.: What I wrote about the RAD-Tools dependency is completely crap. Sorry for being awkward 😇. I'm just learning to deal with Launchpad. When providing the "apt-get install" mechanism, we need to improve our deployment strategy. Because the sources are actually built on Launchpad. Maybe I should make up an issue on its own for that. Just to remember: Providing binary DEB packages is the more "easy way" and similar to a windows installer. Packages just have to be installed by the user in the right order (libraries first). Problem here: MGV itself doesn't start. Do you have some Linux VM? Then please try for yourself: # first run the cmake scripts (I use Qt-Creator)
cd /path/to/RAD-Tools-build && sudo make install
cd /path/to/libGitWrap-build && sudo make install
cd /path/to/libHeaven-build && sudo make install
cd /path/to/MacGitver-build && sudo make install
# run the programm
MacGitverIt will fail to start, like I said on the phone. Seems like |
|
Oh, and yes: you're right a) WiX is indeed an interesting name for a "program that adds something to another person's intimidate data locations" and b) seems like CMake supports this :) Ok, then let's go this way. I'll replace NSIS with WiX in the TODO list. |
|
@antis81, take a step backwards, a deep breath and then think about this again. What you really need to do is:
|
|
Back in the ol' days, when our Git Lab was still alive, we actually had a jenkins job, which actually did exactly that. Grab the sources from all relevant submodules and daily update a git repository with a complete set of all MacGitver sources in one place. |
|
Thanks for that hint 👍! Hm, this is what I'd prefer to re-write the code gatherer as a cmake module. This way it becomes more platform independent. And ... I have to admit I'm not that good in shell scripting |
|
If I get this right, you want to wrap the shell commands from the gatherer inside I'd rather like to have it in a format that can be easily integrated into an automated system and be run automatically... |
|
Not exactly. I'd not wrap it, but write it completely as a CMake module (function or a macro). This way it can be run on win / lin / mac the same way, without the need to write separate scripts for each OS ... and without having to cross-compile. Something like this find_program( GIT git )
if( NOT ${GIT} )
MESSAGE(STATUS "Git was not found on this system.")
return()
endif()
function( git_clone_source REPOSITORIES BASE_DIR)
# we could do a check for existing directories and fetch recursive
# I'd prefer to delete BASE_DIR instead
foreach( REPO IN REPOSITORIES )
execute_process( ${GIT} clone --recursive ${REPO} ${BASE_DIR}/ )
endforeach()
endfunction()
# ... and so on ... |
|
This is still wrapping the commands. Except that it will not become cross platform, since it would still require a msys-style bash on windows to deal correctly with the forward slashes... :) |
|
Well, when having installed Git on Windows, you have an msys bash anyways :). But the real question is. Why should that be bad? We have to run cmake anyways. So why not using it? |
|
Counter question: If you want this kind of bullet-proof, you'll have to write a huge amount of CMake scripts, which is by far not easy. The gain is that a system that is actually not at all meant to be run by any user and is hence just required by the maintainer to execute (or even better be automated in the background), becomes usable on a system which neither you nor me make use of. So, could the time spent on that be spend with a higher valuable output? |
|
btw: If you're using Visual Studio (which probably is still like 90-95% of Windows developers), you'd be advised wisely to avoid all kinds of msys in the first place :) |
|
Slept over that one and it's hard but true. Supporting a system, that none of the developers uses, does not make much sense. Thus, unless someone wants to support a WiX installer, GitWrap for Windows won't get one. Using a shell script is a reasonable way to gather the sources then. Though, I can't tell the difference between cmake and shell script in this context. Except shell script is more flexible when replacing the build system in a far away future :). |
PR to finish the installers for libGitWrap.
To add the PPA write this in a terminal
sudo apt-add-repository ppa:nilsfenner/macgitver-dev(NOT NEEDED) Finish the OSX DragNDrop Installer(USE WiX INSTEAD) Finish the NSIS based installer for Windows(CANCELLED, BECAUSE NOBODY NEEDS IT) Finish the WiX based installer for Windows (create an MSM merge-module)