I'm doing some refactoring (more than what CLion can do automatically) and making lots of changes. When I change a header file, it prompts a significant fraction of my project to rebuild, but I know the error messages will always come from the same spot (which unfortunately starts with "w").
Is there any way to control where CLion will start building so I don't have to wait 30s+ to get the next error message?
I've been typing make src/workflow.o in a console (I tried using the CLion console, but that doesn't make links from errors), but I'd rather have the direct links to the error location.
You can add another cmake target to build only the stuff you need.
See e.g. here:
https://www.jetbrains.com/help/clion/2016.1/creating-and-editing-run-debug-configurations.html?origin=old_help
Related
I am an Eclipse/STS user/developer, now trying to use IntelliJ Idea (CE)
2020.2.(1,2,3)
For a project based on Gradle, how spring-integration, when I open the IDE it happens the following
Ok, let the IDE load the project ... but
From above, that is the problem, I don't want that the IDE starts automatically to build/rebuild the project. I just need, open the project and that's all.
Observation: for example in Eclipse/STS exists the option to disable Build Automatically
I did do a research in the Web and I read the following posts and questions:
How to disable automatic gradle builds?
IntelliJ IDEA “Build project automatically” apparently not working
Intellij IDEA Java classes not auto compiling on save
Sadly the dialog options were changed but ...
Therefore:
From above, seems nothing to do.
Observation: from above observe the Build project automatically option is disabled
Even with that disabled and after to restart the IDE, I must always stop manually the build process
So what is missing? or Do I need a special extra plugin to accomplish my goal?
The images that you show indicate that you are building with Gradle, but the Compiler option that you disable is relevant for building projects with Idea not with Gradle.
For the 2020.2 version, you need to do the following:
Open the Setting > Build Tools page.
Disable the "Reload changes in build scripts" option.
This way you can manually control the reload. When you change the build script, you will see a small gradle icon in the right side of the editor.
For more info, refer to the IntelliJ IDEA help > Gradle section.
https://www.jetbrains.com/help/idea/work-with-gradle-projects.html#auto_reload
There are two different things in IntelliJ's Gradle support that sometimes confused: sync and build. Your pictures demonstrate sync process (note caption on the toolwindow). Word build is kind of misleading here.
What is sync? In gradle we use Groovy to define the build procedure. Groovy is an imperative programming language, so it's hard to predict resulting dependencies graph without actually executing the script. During the sync Idea executes configuration phase of gradle build (one that builds dependency graph), and obtains configured objects from the Gradle daemon. This information is used to setup project in the IDE: modules, libraries, dependencies, which sources are test, which are prod, etc.
Actual build is not happening during sync. You can convince yourself by adding syntax error to any source file, and observe that the sync succeeds. But build will fail if you invoke it.
In answer to the original question: you can't disable automatic build, because it is not enabled.
Is it possible to disable sync in Gradle project? Short answer - no. If you need a code browser, which is not required to understand all the cross-references in the source code, IDEA is not the best choice probably.
TL;DR;
Without sync IDE does not know which files are sources, and which are not. IDEA cannot open folders. It only can open projects. Good thing is that module can contain folder. So you can do the following: File | New | Project. Select Empty project, Next, select some random folder outside the source folder you want to open, Finish.
Then add new module:
Select Java in the left panel, everything else keep default, Next, Finish. Then in new module remove existing content root, and add folder with sources as new content root
Resulting project is mostly useless. Tons of red code (at least, unresolved symbols from external libraries), no inspections, no navigation, no sense. But it might be useful in some rare situations indeed.
Due to:
extensive usage of code auto-generation (notably for the .isa instruction and decoder sublanguage)
scons symlinking sources into the build tree, and in particular symlinking src/arch/ARCH to src/ARCH
it becomes very hard to setup Eclipse to work well with gem5.
Has anyone managed to achieve a good setup? Especially interested in Linux hosts.
I have achieved a very good setup with the following horrendous hack: define the Eclipse project inside the build/ARM directory itself!
This is done by creating a "New makefile project with existing code" in the build directory. You will also want to fix the C++ standard library as mentioned at: How to solve "Unresolved inclusion: <iostream>" in a C++ file in Eclipse CDT?
This works amazingly because the way the gem5 build system works as of May 2020, the build/ARM directory contains exactly the final compilation tree, including all the source symlinks and autogenerated code,.
This setup is not perfect because there is still some C++ stuff in build/ outside of ARM, e.g. ext, but 99% of the time we don't care about those, and I can perfectly navigate key autogenerated code such as instructions and decoder.
I then just build via the command line normally with scons.
Humongous autogenerated files like exec-ns.cc.inc turn on Eclipse's large file limited mode. Notably, if you want to jump to a definition, Ctrl + click does not work for me, so I just copy the symbol of interest and Ctrl + Shift + T to go to its definition.
I don't usually bother to try GDB step debug gem5 through Eclipse and use it mostly for code navigation, since GDB Dashboard tends to work well enough for me, and I often need to do new log collection runs and I sometimes use reverse debugging when things get serious.
But I have tested step debugging through Eclipse, and it did work normally (no reason not to I guess), you just have to set it up in exactly the same was as for any other C++ application with a Makefile, i.e. basically tell eclipse the Binary name and the desired CLI on the debug configurations.
You have of course as usual to choose between a gem5.debug debug build or a gem5.opt build, where the .debug build is about 10-20x slower but gives greater debug visibility. In general, if the time to reach the point of interest in a debug build starts to annoy you however, what you tend to really want is to do use reverse debugging.
This is also mentioned at: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-eclipse-configuration
Tested in Eclipse 2020-03.
I have upgraded my Community version of PyCharm to 2016.3.2, and I'm not positive it was this exact version, but when I went to run files that had unittests in them, only some of them are recognized as UnitTests that I can right click and run.
I have looked to make sure that my classes implement unittest.TestCase
class clWorkflowWebClientTest(unittest.TestCase):
all of my tests begin with test_blahblah()
If I go into Edit Configurations and add one manually, I can right click and run it from the project tree, and it runs as a UnitTest. But I don't get the "Run UnitTests in Blah' dialog when I right click the file.
This turned out to be an issue I caused myself. we had added a folder called 'UnitTest' and introducing this to the path caused issues with PyCharm knowing what was a true UnitTest file.
I still don't know exactly what caused some files to work, but there appears to be one method in those files that did work that was probably being imported from another file that had the proper pathing.
I want to switch my python-IDE from idle to pydev (eclipse). I am using a couple of modules which I have as compiled bytecode (*.pyc) only. In idle that was never a problem and it even offers code completion for those compiled modules. But pydev gives me a lot of "undefined variable" errors - however the code is interpreted correctly.
Is there a way pydev can handle bytecode modules the way idle does? Perhaps without decompiling the files?
Try adding the modules as forced builtins.
To do that, go into Settings → PyDev → Interpreter - (Python/Jython/IronPython as approriate), select the interpeter you're using, and add it to the list on the Forced Builtins tab (look here for more details).
(Note that you may or may not have to add multiple entries for subpackages and modules; for example to get Fabric working properly one needs to add both fabric and fabric.api)
That makes PyDev load those modules into an interpreter to get code-completion and error checking data, rather than just analysing source code.
I've not tried it for .pyc files, but it works for other things like importing something that's generated dynamically by a script's __init__.py or something (ie fabric) so it might work for you.
(see also this FAQ and that one on the PyDev site)
I am getting the above error message randomly (so far as I can tell) on iPhone projects. Occasionally it will go away upon either:
Clean
Restart XCode
Reboot
Reinstall XCode
But sometimes it won't. When it won't the only solution I have found is to take all the source material, import it into a new project, and then redo all the connections in IB. Then I'm good until it strikes again.
Anybody have any suggestions?
[update 20091030]
I have tried building both debug and release versions, both full and lite versions. I've also tried switching the debug symbols from DWARF with external dSYM file to DWARF and to stabs. Clean builds in all formats make no differences.
Permission repairs change nothing.
Setting up a new user has no effect. Same error on the builds.
Thanks for the suggestions!
[Update 20091031]
Here's an easier and (apparently) reliable workaround. It hinges upon the discovery that the problem is linked to a target not a project
In the same project file, create a new target
Option-Drag (copy) all the files from the BAD target 'Copy Bundle Resources' folder to the NEW target 'Copy Bundle Resources' folder
Repeat (2) with 'Compile Sources' and 'Link Binary With Libraries'
Duplicate the Info.plist file for the BAD target and name it correctly for the NEW target.
Build the NEW target!
[Update 20100222]
Apparently an IDE bug, now apparently fixed, although Apple does not allow direct access to the original bug of a duplicate. I can no longer reproduce this behaviour, so hopefully it is dead, dead, dead.
Troubleshooting steps:
(1) dsymutil deals with debug information so you should probably start with the debug build. Once the problem starts can you run the release build?
(2) Create a new users and work from there to see if the problem follows. If not the problem is most likely a corrupted file in your user's directory.
(3) In my experience most linker problems are caused a permission problem somewhere. (We have to pay for security.) I would repair permissions and see if the problem goes away.
(4) In the extreme you can uninstall the dev tools from the command line:
sudo /Developer/Library/uninstall-devtools --mode=all
However, this won't help if the problem is in your user's directory. In that case, you might need to work under a new user or spend a lot of time tracking down every dev related file in the user directory.