I would like to force my cmake based configuration to fail ( and possibly print a message ) if:
there are unused variables ( which are likely to be a typo in most cases )
there are unused modules ( same thing as before or useless stuff )
a particular if is not being evaluated to TRUE
I find that the fact that cmake is macro based solution makes it hard to spot errors on big projects, so if someone has some some hints on that. Basically cmake doesn't alert you because anything could be a custom variable and not necessarily a typo or a mistake.
Let's address your points out-of-order.
a particular if is not being evaluated to TRUE
The way to achieve this is a FATAL_ERROR message:
if(SOME_CONDITION)
message(FATAL_ERROR "You did something wrong!")
endif()
there are unused variables
This is more difficult. There are the --warn-unused-vars and --warn-uninitialized command line options, but this has to be given by the user when running CMake. It is not possible to enforce this behavior from within a CMake script.
Also, there is no way to turn these warnings into fatal errors: CMake will still try to produce a valid Makefile (and may succeed in doing so). The only viable solution here seems to be developer discipline: Whenever a developer makes changes to the build environment, they should be aware of this compile options and check their code accordingly. Just as you would do with your other source code.
If you have trouble enforcing this, try to provide a shell-script as a wrapper that already sets all of the desired command line options. While not perfect, this will at least remove the obstruction of having to look up that damn parameter in the manual for your developers.
there are unused modules
This is not possible, but I also don't see a big problem here. Worst thing that can happen is that pulling in the module adds some noise to the cached variables, but none of that would have any influence on the final generated build files.
CMake modules should always be kept small enough so that pulling them in should have no noticeable impact on the runtime of your CMake configure run.
Related
I would like to identify all functions needed to run a specific function in octave. I need this to deploy an application written in Octave.
While Matlab offers some tools to analyse a function on its dependencies, I could not find something similar for Octave.
Trying inmem as recommended in matlab does not produce the expected result:
> inmem
warning: the 'inmem' function is not yet implemented in Octave
Is there any other solution to this problem available?
First, let me point out that from your description, the matlab tool you're after is not inmem, but deprpt.
Secondly, while octave does not have a built-in tool for this, there is a number of ways to do so yourself. I have not tried these personally, so, ymmv.
1) Run your function while using the profiler, then inspect the functions used during the running process. As suggested in the octave archives: https://lists.gnu.org/archive/html/help-octave/2015-10/msg00135.html
2) There are some external tools on github that attempt just this, e.g. :
https://git.osuv.de/m/about
https://github.com/KaeroDot/mDepGen
3) If I had to attack this myself, I would approach the problem as follows:
Parse and tokenise the m-file in question. (possibly also use binary checks like isvarname to further filter useless tokens before moving to the next step.)
For each token x, wrap a "help(x)" call to a try / catch block
Inspect the error, this will be one of:
"Invalid input" (i.e. token was not a function)
"Not found" (i.e. not a valid identifier etc)
"Not documented" (function exists but has no help string)
No error, in which case you stumbled upon a valid function call within the file
To further check if these are builtin functions or part of a loaded package, you could further parse the first line of the "help" output, which typically tells you where this function came from.
If the context for this is that you're trying to check if a matlab script will work on octave, one complication will be that typically packages that will be required on octave are not present in matlab code. Then again, if this is your goal, you should probably be using deprpt from matlab directly instead.
Good luck.
PS. I might add that the above is for creating a general tool etc. In terms of identifying dependencies in your own code, good software engineering practices go a long way towards providing maintenable code and easily resolving dependency problems for your users. E.g: -- clearly identifying required packages (which, unlike matlab, octave does anyway by requiring such packages to be visibly loaded in code) -- similarly, for custom dependencies, consider wrapping and providing these as packages / namespaces, rather than scattered files -- if packaging dependencies isn't possible, you can create tests / checks in your file that throw errors if necessary files are missing, or at least mention such dependencies in comments in the file itself, etc.
According to Octave Compatibility FAQ here,
Q. inmem
A. who -functions
You can use who -function. (Note: I have not tried yet.)
I am using TCL as an embedded control in my system and I need to modify its core source a bit, I mean the code under generic/, such as tclInterp.c. I am adding printf to the source code to trace my modification, but for some reason I cannot see the output. I see the code is using fprintf, I used that and tried both stdout and stderr, still not working.
I already added "--enable-symbols=all" to run configure and re-build the packages. Is there anything else I need to do?
You should use a debugger instead. Adding printf statements to the core code will result in your output appearing on stdout which your Tcl scripts may redirect. using fprintf(stderr, ...) might be less likely to clash with the scripts you run. --enable-symbols just results in a debuggable build - it will not affect the ability to write to stdout but will result in a debugger being able to produce meaningful output.
You don't say - but if you are on Windows and are embedded in a graphical program then you probably don't have stdout anyway. On Windows, you will be best to use OutputDebugString and watch the messages in Visual Studio's output window or sysinternals DbgView.
On unix, the console you launch the application should show the output. However, actually tracing your mods with a debugger will be the best route.
Are you sure you really need to modify the core? Seems unlikely to me. Normally you just add additional commands to the interpreter to provide the interface to your hosting application. The Tcl API offers access to pretty much everything you might reasonably want to fiddle with.
Why is changing lines in configuration file considered an anti-pattern in Chef or Puppet?
It's something like bad habit, as I understood. I assume that this file-editing is done in some idempotent way and with advanced tools (augeas for example).
Why is deploying the whole files, with ERB templates, considered a preferred method?
You can find a lot of examples where dev-ops are suggesting usage of templates instead of file-editing. For example here, here, here, etc.
Actually there is a large part of the DevOps community that sees accepting system/package defaults for config files and only modifying what you need through augeas as the preferred method, Github devops would be one of them(if you happened to catch them at Puppet Conf 2012).
I think having a default pattern of always using templates creates too high of a maintenance load and almost always requires you lock in specific versions for everything across your stack or you risk having an incompatible template against a newer version of that resource.
There's use cases for both options but in general I favor the "own as little as possible" practice vs the "own everything even if you don't have to" practice.
In terms of setting the your system to a known state, deploying whole files is better than editing, because you are sure the file is exactly as intended when you are done.
If you are tinkering around finding potential solutions to a problem and hand edit some configuration file, you don't have to worry about the hand edit you made staying around as an uncontrolled part of your environment. The next time you run chef-client, you know that the state will be exactly as specified in the Chef recipe, and won't include your edit.
Also, it is just in general harder and more complicated to robustly edit a file than it is to just generate one. You might write something that is idempotent in the basic case, but if the file contains a syntax error or something invalid, than your editing no longer works.
As always though, sometimes you don't have a choice, and editing is the only way to go.
There is some performance issue if I let my traces around the whole code when releasing?
trace("thank you");
Traces are ignored in release builds so there is no performance penalty.
Yes there is a performance issue if you have traces active
Some compilers have specific compiler options stating something similar to "build release client", these might or might not end up with a build where all trace-comments does not exist [are ignored].
Even if you don't have anything listening to trace-statements and they are running, it will first of all do an extra function-call and checking some if-statements, then after that it will be stored inside a log-file on the computer where it is run.
So, you should find out what compiler you have and if that one automatically removes trace-messages when compiling in "release mode". If not, you have to either ignore the performance loss or find ways to work around it
I'm working on a Mercurial GUI client that interacts with hg.exe through the command line (the preferred high-level API, as I understand it).
However, I am having trouble determining the possible outputs of each command. I can see several outputs by simulating situations, but I was wondering if there is a complete reference of the possible outputs for each command.
For instance, for the command hg fetch, some possible outputs are:
pulling from https://User#server.com/Repo
searching for changes
no changes found
if there are no changes, or:
abort: outstanding uncommitted changes
or one of several other messages, depending on the situation.
I would like to structure my program to handle as many of these cases as possible, but it's hard for me to know in advance what they all are.
Is there a documented reference for the command-line? I have not been able to find one with The Google.
Look through the translation strings file. Then you'll know you have every message handled and be able to see what parts of it vary.
Also, fetch is just a convenience wrapper around pull/update/merge. If you're invoking mercurial programmatically you probably want to keep those three very different concepts separate in your running it so you know which part failed. In your example above it's the 'update' failing, so the 'pull' would have succeeded and the 'update's failing would allow you to provide the user with a better message.
(fetch is an abomination, which is part of why it's disabled by default)
Is this what you were looking for: https://www.mercurial-scm.org/wiki/MercurialBook ?
Mercurial 1.9 brings a command server, a stable (in a sense that API doesn't change that much) and low overhead (there is no need to run hg process for every command). The communication is done via a pipe.