Thanks for confirming that re-running cmake will aid in the dependency resolution.
Looks like setting variables and parameters with cmake-gui are straight forward here in the link below.
What you should absolutely know as a package maintainer is to differentiate (categorize) build error types, knowing the type of error will make error resolution easier, there are:
- Build errors
- Compile time errors
- Link time errors
- Syntax errors
- Run time errors
Build error may be related to build scripts used by build system or be caused by build system itself (ex. Cmake itself or it's Cmake files) but it may also be any of the 3 other listed errors above because each one will also make whole build process fail, so when somebody says "build fails" they're not saying enough.
Compile time error is an error thrown by a compiler, it fails due an error in the code which is most commonly due to a syntax error.
To fix compile time error you either downgrade your source tree (ex. whole code which you clone with git and build) to some previous or later version or fix an error in the code yourself.
Link time errors happen after the compiler is done compiling, it happens in link stage because a linker cannot link together outputs of the compiler with dependencies (libs) if there are any. (usually because some dependencies or source files or symbols in source files or libs are missing).
When fixing linker errors first step is to figure out whether it's caused due to missing library or missing source file or missing symbol in the source file or external library. ("symbol" may refer to a function definition, a variable or any other language construct that's needed to be present in compiler output or linker input)
Syntax errors are programmer errors or typos in code and fixing them can only be done by editing code or by applying a patch if there is one.
Run time errors are those which happen while a program is executed and running, fixing those requires debugger, this is meaningful to you if in addition to building you also need to make sure build output (ex. an executable) executes and works fine on system.
These of course means that build process will always succeed but then program won't run as it should.
Run time error can be caused either due to a bug or due to logic in code which catches the error and terminates the program or displays (and logs) an error message.
It sounds like from your description, to apply a patch I'll need to install git, is that correct?
Yes, but patches are so rare, I can count on my fingers how many time I've stumbled upon a patch somewhere online.
You can think of every git commit that you can browse on GitHub or elsewhere as of a patch, so usually you simply use git to update your source tree or switch to another branch etc.
If you ever happen to stumble upon and need a patch it will be from some external website (ex. mailing list) or from GitHub but a commit that was not yet merged with current branch for what ever reason.
Would re-learning Python or Perl help?
Build process or debugging scripting languages is different or there is no build process at all, that's why they're called scripting languages because they're not compiled into an executable but consist of scripts that are outright run and processed by interpreter.
I know almost nothing about these but each scripting language does provide some tools to debug them or to confirm they're error free.
In some big projects such as game engines or games you'll find a mix of compiled language sources and scripts, the procedure there is different because usually a compiled language libs like C\C++ libs provide interfaces for scripting, ex. to bind with Python for AI logic, in these cases those scripts are not run by a user but by the main program that's compiled so build process will almost always succeed but if there is error it's going to be run time error or a bug related to those scripts.
So I think learning scripting languages is of very little use to someone who is package maintainer unless you also need to test what you build.
Agreed, that method is harder however, I'm up for the challenge for one and two, if I can get the basic's down I can contribute my builds.
I see, in this case, my suggestion to create custom project files for this is bad because you should use tools that are provided to you by distro for which you build.
Custom project method is great if you build something for yourself and plan to maintain it for yourself, for distros you'll go by their rules as they surely won't accept your build projects.
Custom project is still useful to figure out why build fails, but in the end you'll have to apply your failure discovery so that it's in line with their build rules.
