Today I'm on a mission to remove little red X's from my django project in pydev. Mostly, this involves fixing import problems with pydev.
I'm using South for database migrations. South (if you don't know) generates python modules, and pydev doesn't like them. I don't want to edit the south code since it's generated.
Is there a way to instruct pydev to exclude certain packages from analysis? Something like ##UndefinedVariable, except for the entire module? Ideally I'd like to ignore packages named "migrations".
In South, I have added a "##PydevCodeAnalysisIgnore" to the templates in south/management/datamigration.py and south/management/schemamigration.py. It doesn't let me ignore entire packages, but serves my purposes well enough.
I have lots of generated code. To avoid PyDev complaints, I postprocess those modules as follows (bash script):
for file in `find gen -name '*.py'`; do
mv $file $file.bak
echo '##PydevCodeAnalysisIgnore' > $file
cat $file.bak >> $file
rm $file.bak
done
Yes, you can put ##PydevCodeAnalysisIgnore at the beginning of each file that you want to ignore, but that means that you're coding to your IDE, which isn't best practice. I prefer instead to change my project settings so that
some troublesome patterns are ignored by Eclipse (by adding to Preferences -> PyDev -> Editor -> Code Analysis -> Undefined)
some troublesome files are ignored by Eclipse (by adding an exclude filter to Project Properties -> Resource -> Resource Filters -> Add Filter...)
In your particular case, I had the exact same problem and decided to exclude South migrations from the Eclipse project. On the few occasions that I needed to edit these auto-generated files, I didn't use Eclipse.
UPDATE:
One other option is to right click on your project and select PyDev -> Remove error markers -- but don't do this if there are any errors that you don't want hidden!
Although not directly related to this question in terms of disabling individual migration files from analysis, PyDev's built in code analysis was causing me real headaches here on Windows, when the same project and settings has no problem on Mac OS. This lead me to this question, on how disable analysis for certain resources. There is a large folder part of the project and excluding this resource using Eclipse -> (the folder) -> Properties -> Resources -> Filter (exclude) didn't even help.
Having the exclusion along with using PyLint fixed the insanely slow build times. YMMV.
Related
I love the JetBrains tools. But, I can't find a way to effectively share settings at the IDE level and the project level with team members. To date, I've followed instructions provided by an article on the JetBrains site, titled "How to manage projects under Version Control Systems". But, many comments on the article warn against implementing it as a method for sharing project settings. And I've run into a few issue with the method, namely not everything I'd like to be shared, is actually shared with team members.
I've also tried using the function found under the File->Settings Repository menu of the JetBrains tools. It shares some settings between users, and I like that it automatically creates commits to the Git repo, but it doesn't share all the settings. The settings that are shared work great! But, it seems like the "Settings Repository" feature is a work in progress.
I've read many discussions on this topic, but no definitive answer on a way to share IDE level settings and, at the same time, project specific settings when using the JetBrains tools. Not to mention, I use a multiple JetBrains tools (PhpStorm, PyCharm, WebStorm and IntelliJ). I'd like it if there were a solution that also shared settings between all the tools, because some settings are global across all JetBrains tools, some are specific to a particular tool, and some are specific to a project.
Sharing settings between JetBrains tools is more of a "nice to have". What I really need to know is, how can I share global IDE settings and project level settings easily between team members. But, I'll give mad respect points to anyone who can figure out both. :-)
I finally found a few minutes to write up an answer to this. I want to write up a more complete answer, but I've been incredibly busy lately so this will have to do for now.
This solution describes what I've been using to share code and settings of PyCharm projects. There is one caveat to this solution, which I'll attempt to describe and detail a work-around for.
Following the instructions on JetBrain's knowledge-base, we'll add the entire project folder to a Git repo. But, before doing so, be sure to exclude at least the workspace.xml file by creating a .gitignore file in the project directory and add at least the following line:
.idea/workspace.xml
# JetBrains also recommends adding tasks.xml, but I found it useful to
# share tasks with team members.
# Uncomment the following line to avoid sharing tasks with team members
# .idea/tasks.xml
You'll definitely want to add workspace.xml to .gitignore because it stores all of your local window sizes, debug panel layouts and the like. My team found it useful to syncronize our tasks, so that we could coordinate work. But, every team works differently, so use your own discretion.
There are three main locations project and personal preferences are stored:
<project_directory>/.idea contains project specific settings.
$HOME/.PyCharmYYYY.M/config contains options for all projects managed by PyCharm (or substitue "PyCharm" for any other JetBrains tool).
If you use the shared settings found in File->Settings Repository, $HOME/.PyCharmYYY.M/config will contain all of the settings shared via JetBrain's built in "shared settings" function. I and my team didn't care for it, because it seemed to automatically share some things we didn't want to (like the color theme, and key mappings). And we weren't able to select a sub-set of options to share team-wide. Long story short, it didn't give us the flexibility and control we need.
We did try using options 1 and 3 at the same time, but it was too unwieldy. For example, one person would change a font, and it would change it for the whole team the next time we re-launched JetBrains. It was a mess. If you do decide to try out using options 1 and 3, I recommend proceeding with extreme caution.
Presently, we are using only option 1, and it's working out quite nicely.
A few other notable folders you might want to add or remove from the .gitignore file are:
<project_folder>/.idea/runConfigurations/ contains all of your debug and run configurations used to run nose tests and debug into your code.
<project_folder>/.idea/scopes/ contains all of the scopes used to filter your view of the project files, into more management groupings.
$HOME/.PyCharmYYYY.M/options contains all of the global options for version of PyCharm you're using. For example, the color scheme, key mappings and any other non-project specific options. For a full list of other global settings, see this JetBrains article, or the following excerpt:
The CMake doc says about the command file GLOB:
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.
Several discussion threads in the web second that globbing source files is evil.
However, to make the build system know that a source has been added or removed, it's sufficient to say
touch CMakeLists.txt
Right?
Then that's less effort than editing CMakeLists.txt to insert or delete a source file name. Nor is it more difficult to remember. So I don't see any good reason to advise against file GLOB.
What's wrong with this argument?
The problem is when you're not alone working on a project.
Let's say project has developer A and B.
A adds a new source file x.c. He doesn't changes CMakeLists.txt and commits after he's finished implementing x.c.
Now B does a git pull, and since there have been no modifications to the CMakeLists.txt, CMake isn't run again and B causes linker errors when compiling, because x.c has not been added to its source files list.
2020 Edit: CMake 3.12 introduces the CONFIGURE_DEPENDS argument to file(GLOB which makes globbing scan for new files: https://cmake.org/cmake/help/v3.12/command/file.html#filesystem
This is however not portable (as Visual Studio or Xcode solutions don't support the feature) so please only use that as a first approximation, else other people can have trouble building your CMake files under their IDE of choice!
It's not inherently evil - it has advantanges and disadvantages, covered relatively well in this answer here on StackOverflow. But if you use it carelessly, you could end up ignoring dependency changes and requiring clean rebuilds of large parts of your codebase.
I'm personally in favor of using it - in smaller projects, or on certain subdirectories in larger ones - to avoid having to enter every file manually into the build files. Edit: My preference has changed and I currently tend to avoid it.
On top of the reasons other people here posted, imho the worst issue with glob is that it can yield DIFFERENT file lists on different platforms. As I see it, that's a bug. In OSX glob ignores case sensitivity and in a ubuntu box it doesn't.
Globbing breaks all code inspection in things like CLion that otherwise understand limited subsets of CMakeLists.txt and do not and never will support globbing as it is unsafe.
Write script to dump the globbed list and paste it in, its very simple, and then CLion can actually find the referenced files and infer them as useful. Maybe even put such script into the tree so that the other devs can either run it without being a moron OR set git hooks to make it happen.
In no case should some random file dropped into some directory ever get automatically linked that's how trojans happen.
Also CLion without context jumping to known definitions and what not, is like hiking barefoot /// why bother.
In a simple IntelliJ module, I just want to generate a .jar file with my .class files, via IntelliJ IDE commands.
Please be careful before marking this as a "duplicate":
Although I've seen Google and Stack hits with promising titles, I'm not finding a really good answer, or the title is misleading, or its an unanswered question. I cover one possible answer that I've seen before (below), and why I don't think it's a match.
I've used Eclipse in the past, but I'm rather new to IntelliJ.
I've worked with the "Project Structure / Artifacts" stuff. I can generate the giant jar, similar to using "shade", but it's huge because it includes all the nested dependencies. We want the small jar with just this module's class files because the system we're deploying to already has all the other jars in place.
I've seen some references to changing a target directory in the Artifacts dialog box, but it then talks about references being made in the Manifest file, which I don't want. The destination environment already has its java paths setup, so I'm worried that having jar references in this jar will mess that up. If this really is the answer then I'm confused about how it works.
Constraint 1: Can't use command line tools, since I'm actually walking somebody else through these steps, who likely doesn't have command line tools installed in the path, or wouldn't know how to use them, etc. They're not a coder. (Yes, I know this sounds like an odd scenario; I inherited this situation.)
Constraint 2: We want to keep this as a simple IntelliJ project, vs. converting to Maven or Ant or Gradle, etc.
Coworker had the fix.
Short Answer:
Remove all of the other jars/libraries from Output Layout tab of the Artifacts config dialog.
Longer Answer:
You still do File / Project Structure...
Then in the Project Settings, click Artifacts.
And then you still click the plus button (second column) ti create a new artifact setting.
The trick is the "Output Layout" tab in the third column of the window. Highlight all entries EXCEPT the compiled output of your project and delete all those other entries (click the minus button under that tab, directly above your_project.jar)
On my laptop this causes it to pause for a few seconds; I thought it didn't do anything, then finally it reflected that everything was gone except "'my_module' compile output"
Also check the "Build on make" (for when you later do Build / Rebuild Project)
If you need both a full jar and a slim jar, you can have more than one Artifact configuration with different names, and they will default to different output directories.
I am trying to clean up some of my projects, and one of the things that are puzzling me is how to deal with header files in static libraries that I have added as "project dependencies" (by adding the project file itself). The basic structure is like this:
MyProject.xcodeproj
Contrib
thirdPartyLibrary.xcodeproj
Classes
MyClass1.h
MyClass1.m
...
Now, the dependencies are all set up and built correctly, but how can I specify the public headers for "thirdPartyLibrary.xcodeproj" so that they are on the search path when building MyProject.xcodeproj. Right now, I have hard-coded the include directory in the thirdPartyLibrary.xcodeproj, but obviously this is clumsy and non-portable. I assume that, since the headers are public and already built to some temporary location in ~/Library (where the .a file goes as well), there is a neat way to reference this directory. Only.. how? An hour of Googling turned up blank, so any help is greatly appreciated!
If I understand correctly, I believe you want to add a path containing $(BUILT_PRODUCTS_DIR) to the HEADER_SEARCH_PATHS in your projects build settings.
As an example, I took an existing iOS project which contains a static library, which is included just in the way you describe, and set the libraries header files to public. I also noted that the PUBLIC_HEADERS_FOLDER_PATH for this project was set to "/usr/local/include" and these files are copied to $(BUILT_PRODUCTS_DIR)/usr/local/include when the parent project builds the dependent project. So, the solution was to add $(BUILT_PRODUCTS_DIR)/usr/local/include to HEADER_SEARCH_PATHS in my project's build settings.
HEADER_SEARCH_PATHS = $(BUILT_PRODUCTS_DIR)/usr/local/include
Your situation may be slightly different but the exact path your looking for can probably be found in Xcode's build settings. Also you may find it helpful to add a Run Script build phase to your target and note the values of various settings at build time with something like:
echo "BUILT_PRODUCTS_DIR " $BUILT_PRODUCTS_DIR
echo "HEADER_SEARCH_PATHS " $HEADER_SEARCH_PATHS
echo "PUBLIC_HEADERS_FOLDER_PATH " $PUBLIC_HEADERS_FOLDER_PATH
.
.
.
etc.
I think that your solution is sufficient and a generally accepted one. One alternative would be to have all header files located under an umbrella directory that can describe the interface to using the depended-on libraries and put that in your include path. I see this as being similar to /usr/include. Another alternative that I have never personally tried, but I think would work would be to create references to all the headers of thirdPartyLibrary from MyProject so that they appear to be members of the MyProject. You would do this by dragging them from some location into MyProject, and then deselecting the checkbox that says to copy them into the project's top level directory. From one perspective this seems feasible to me because it is as if you are explicitly declaring that your project depends on those specific classes, but it is not directly responsible for compiling them.
One of the things to be wary of when addressing this issue is depending on implementation-specific details of Xcode for locating libraries automatically. Doing so may seem innocuous in the meantime but the workflows that it uses to build projects are subject to change with updates and could potentially break your project in subtle and confusing ways. If they are not well-defined in some documentation, I would take any effect as being coincidental and not worth leveraging in your project when you can enforce the desired behavior by some other means. In the end, you may have to define a convention that you follow or find one that you adopt from someone else. By doing so, you can rest assured that if your solution is documented and reproducible, any developer (including yourself in the future) can pick it up and proceed without tripping over it, and that it will stand the testament of time.
The way we do it is to go into build target settings for the main project and add:
User Header Search Path = "Contrib"
and check that it searches recursively. We don't see performance problems with searching recursively even with many (10-15 in some projects) dependencies.
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.
Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?
EDIT-- Some related questions:
Git and pbxproj
Should I merge .pbxproj files with git using merge=union?
RESOURCES:
http://www.alphaworks.ibm.com/tech/xmldiffmerge
http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge
http://tdm.berlios.de/3dm/doc/thesis.pdf
http://www.cs.hut.fi/~ctl/3dm/
http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/
Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.
Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.
Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.
Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.
For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.
Define a common "Source Tree" for your code, and a second for 3rd party sources.
There are external build tools available. This may be an option for you (at least, for some of your targets).
At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.
You might want to try https://github.com/simonwagner/mergepbx/
It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.
Disclaimer: I am the author of mergepbx.
The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.
Add this to your .gitatributes file:
*.pbxproj -crlf -diff -merge
To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge).
now click "left" button and open xcode project main directory.
click "right" button and open xcode project main directory to compare.
Now click "merge" button!
Thats it!
Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch.
Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.