What do I miss in using CPackDeb? (cmake version 3.5.1)
For example, if I want to find out CPACK_DEBIAN_PACKAGE_ARCHITECTURE, an empty string is returned. If I clone the respective code, everything works as expected. Also, other
https://cmake.org/cmake/help/v3.0/module/CPackDeb.html specific variables seem to not work, and also my KDevelop does not highlight them.
Since using include(CPackDeb) results in error message CPackDeb.cmake may only be used by CPack internally, I presume there is some other way (a missed parameter?) to activate it.
Related
SUMMARY:
I need the most efficient workflow to individually edit over 200 files, and have them automatically disappear from the search results as they are updated.
DETAILS:
I am in the process of adding logging throughout a legacy system, and need to update over 200 files, each with their own custom code. I need to edit them one by one, and would like for the updated files to automatically disappear from my working search results after I have completed each one. The idea is to know how many and which ones still need to be updated as I slowly work through them all.
I already had to do something similar a few months ago, but on a much smaller scale, and I used an old-school HACK to do it. I did a search and replace for my keyword, and intentionally misspelled it. I then used the misspelled keyword for my search, and corrected it when editing each file, hence automatically removing it from the list. It "works", but is obviously a TOTAL HACK.
I recently started using IntelliJ IDEA, and am not yet familiar with the more advanced features like Find in File Scopes, Search Structurally, Search Templates, etc., but I am sure there HAS to be a "correct" way to do this in IntelliJ, and I just don't know how.
I am currently using "Find in Files" to work through the list, and recently found "All Changed Files" in the Scope list, which is actually the EXACT OPPOSITE of what I need. Is there a way to show "All UNCHANGED Files"??? That would work PERFECTLY in a pinch! But really, I would rather learn the CORRECT way to do this in IntelliJ.
Thanks!
When I save a method and get back to it later, all of my variable names become temp and all of my parameters becomes arg and the code indentation get changed.
Any thoughts on how I can fix this?
The behaviour that you are experiencing is not code formatting at all. You immage is experiencing an issue where it can't access original source code. Thus it uses a backup solution and decomples method bytecode. During the compilation process the variable names are erased, so they can't be re-created during the decompilation, and generic substitudes are used instead.
Now, why you are missing sources is another question. First of all it's important to check if you get some exceptions. Often these happen when you open or save your image, but also thaty may occur when you save methods.
Depending on the Pharo version you may be missing .changes or .sources files. This often happens when you more an image without moving other supporting files.
autoscan produced a series of function checks (AC_FUNC_* and AC_CHECK_FUNCS), and AC_CHECK_HEADERS. Now I need to pull in gnulib code. Do I just try to import every function and header that autoscan identified? Half of them don't show up in the gnulib-tool --list output. Or do I wait until ./configure fails on some platform?
My suggestion would be to ignore autoscan entirely and instead try to figure out which platform you're targeting.
In particular autoscan will try to add tests for functions that are available in every single platform since 1990, but might be missing on a non-SysV OS for instance.
Start with a base platform target (such as C99 and the latest POSIX), and then figure out which other OSes you want to target and what they are missing.
Don't try to cover bases for OSes you have no access to, it's likely you won't actually know what is needed for them to build, let alone run.
Full disclosure: I have changed my opinion on gnulib over the years and not suggest it to be used anymore, if at all possible.
There are two ways to determine which list of gnulib modules you might need:
You can scan your source code or your object files (with nm) by hand.
You can import all the POSIX header file modules via gnulib-tool, then add -DGNULIB_POSIXCHECK to the CFLAGS, compile your package, and analyze the resulting warnings.
Also, some gnulib overrides exist for the sake of old platforms only. You can read the list of what each override fixes, and apply your own judgement.
I honestly can't even find anything like this anywhere on the internet, seems kind of like an obvious feature that is missing.
Basically, I'd like the compiler to check the names of every local variable and cause a build to fail if certain variable names are used. Just as an example, I'd like the build to fail if someone tries to use "x" as a variable for anything.
I get that determined folks would find a ways around it, but I'd like to see if it could be done.
I'm interested more in hearing if this can be done in Visual Studio since that's just what I use the most, but I'd be interesting in hearing about any kind of feature like this for any language / compiler if you know of one.
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.