I have a project that uses both PHP and Python, and I would like to use JetBrains IDEs (in this case PhpStorm and PyCharm) to work with both languages.
However when I open the project using both IDEs concurrently I get a pop up whenever I switch from one to the other, as the newly focused IDE detects metadata that has been written to the project directory by the other IDE. I imagine this would be a problem between other combinations of JetBrains IDEs as well (hence the use of the generic jetbrains tag).
I have a work around (I will post in an answer for others to view), but it is somewhat awkward to set up, and I may well be working with other projects that use the same combination of languages.
Is there an easier solution?
My current workaround:
Create a new directory separate to the main project directory - using the language specific IDE for the second-most used language in the project, open the new directory as a project, and using the options in Settings > Project > Project Structure, add the main project directory as a separate content root.
Whenever needing to work on the parts of the project written in the secondary language, you can now open the new directory instead; this keeps metadata for both IDEs separate.
A workaround which allows for two IDE's to share the same directory without IDE settings conflicts.
JetBrains software allows you to store project settings as either a file based project (*.iml), or a directory based project (.idea).
To choose file or directory based projects, change the file storage type when opening a project.
Note: Directory based projects are preferred to file based projects, as they allow for versioning of shared settings. Support for file based projects is deprecated and may be removed.
Related
I have update PhpStorm to v2016.3.2 and now I can have added multiple projects to Project tool window.
Problem is that when I try to Ctrl+click on some class that is located in both projects IDE does not look only in project, but in all projects and shows Multiple Implementations note (Note: Class is unique per project).
Also looks like PHP functions documentation shows same Multiple implementations note. One in actual PHP dir, other in PhpStorm plugins dir.
How to solve these issues?
With latest phpStorm 9 we have new feature called simultaneous tags editing.
This is generally very nice feature that i'd like to use, but i have one old project with very bad code with a lot of mixed PHP, HTML and JS code, where it breaks code.
I know i can disable this in settings->editor->General->simultaneous tag editing, but it disables this feature for whole phpStorm. Is there way to disable it only per one project?
Is there way to disable it only per one project?
Nope -- this is an IDE-wide setting.
The only possible solution I can think of is to have separate PhpStorm installation that will use custom folders to store IDE settings (look into idea.properties file from PhpStorm distribution, e.g. on Windows 7 it would typically be %PhpStorm-Install-Folder%\bin\idea.properties).
With IDE settings stored in different location you can now configure this installation with different settings (e.g. have that option turned off). Obviously, all settings here will be different to your original setup, unless you configure it the same way or will keep certain config files synced (e.g. Keymaps, Color, Web Servers, Live Templates and other things could easily be synced on file level).
Just remember to launch this installation when you want to work with that specific project.
This is a very basic question, but I have not been able to find the answer anywhere.
I just got Cocos 2Dx 3.3, made a new project and built the HelloWorld scene that was generated.
It generated projects for all platforms, but I am currently compiling and running the Mac project using XCode.
I can easily add new files using XCode, but of course it only adds it to my XCode Project. I would have expected a way to automatically modify all projects at once to add files or change compiler settings. I saw that there is a CMake file, probably used for command line compilation, but I cannot find a way to use that to regenerate the projects for all platforms.
Is it possible to automatically add a file to all platforms? Maybe it is possible to modify the template directory os Cocos and use the cocos new command line to recreate the project from scratch?
Or is it better to do all that manually?
Such an automation would imply parsing of a project file, finding list of relevant files and then changing all the dozen of project files. Which is hell of the work.
Even if it was implemented, how would this implementation decide which project file is a main one? (to get filelist from) And if your projects all have different lists of files? This would need merging etc. etc.
For now cocos new only copies files from one place to another. Frankly, Cocos2d-x have much more serious problems to solve, so I don't think this feature will ever be implemented.
However, you could customize project files/folders to your needs to make process of adding files more or less convenient and sometimes even automatic. Here are some clues:
It is easy to change Android and Linux Makefiles so they will pick up all the source files from a specified folder. Just use wildcards. Resource files are picked up by default.
For Visual Studio solutions (Win32, Win8, WinPhone) you could enable "Show all files" to see all files that either added or not. Unfortunately you can only see files down in the folder tree relative to project folder. To see Classes folder, make a symlink (link /j) of a Classes folder near .vcxproj file. You'd better don't copy/move project folder after it. And don't forget to add this linked folder to ignore list of your versioning system, or you will end up with duplicated files. Resource files are picked up by default for Windows projects.
I am not aware of any solution for XCode project, so you basically stuck with manual source file addition. Which is most annoying among all platforms. However it can pick up resource folders with all files.
Anyway, I would be glad if someone would proof me wrong and would write some kind of script to solve this problem (and also to change project name, company id, automatic versioning, etc.). I believe it could be done more or less reliably with, let's say Python and some regex magic. At least until project file formats will change.
I develope an open source application. Directory structure of my project is:
app
|-include
|-src
|-doc
|-build
|-lib
|-bin
I want to use another open source library. There are some choises:
Add third-party library source code to include and src directory.
Compile third-party library and add to include and lib directory.
Create a third_party directory and add complete source code of third-party library to it.
Create a third_party directory and add compiled of third-party library to it.
What is the best choise? Is there any better way to manage directory structure of a project that uses third-party open source library?
If you are ever planning to upgrade the third-party library, it will be much more convenient to keep it in a specific subdirectory. You don't have to have a specific "third-party" directory; you could name it after the library.
Think about what goes in version control.
If you are copying the third-party library into your repository, then you SHOULD NOT include compiled products (using source instead), as they are typically impossible to diff and platform-specific.
If the user is going to obtain the library separately and add it to your project's tree, then using a subdirectory will make it easier to unarchive and guarantee there won't be any name conflicts; source versus binary should be left up to the user.
At the other extreme, if you are using a reference your VCS manages (such as SVN externals or Git submodules), you will probably have to include the source in a subdirectory.
One concern you should bear in mind, depending on your situation, is whether you will someday have to account for those third party open source components and compliance with the licenses etc.. It can be easier to manage this kind of thing if you keep the third party files in their own directories. Having the unmodified source code and licenses handy and a link back to where you got the source code and could get it again would be useful as well. I've worked at companies where there were license compliance verification processes that were easier to get through if the third party sources were segregated in this fashion.
https://softwareengineering.stackexchange.com/questions/234511/what-is-the-best-practice-for-arranging-third-party-library-licenses-paperwork is relevant on this.
(my apologies for the non-specific wording of the question title, and for liberal use of öpen source" when I actually mean "project setup at SourceForge")
We have recently open sourced a 3D modeler we'd been selling for a couple of years, with the main goal of keeping the application alive. We setup shop at SourceForge.net, and are now working towards a process resulting in a steady flow of binary releases. So far, everything is swell.
However, besides the main application, we had also developed a couple of plugins (mainly for different import/export formats). Currently, these are still closed source, but we would like to open those up as well (3rd party plugin developers can take care of their own or donate and open the source). The question really is, should our plugins be hosted as a project on their own or not?
The options I see are:
Add the plugin sources into a subfolder of the SVN sources
Create a separate project for the set of plugins
Create a seperate project for each individual plugin
Which setup is the most practical and/or common, and how should I deal with the binaries?
When the application was still closed and commercial, it was kinda important that the plugin binaries could be updated seperately fom the main application, but now that everything is open and updated frequently, that's not so much of a big deal anymore. Also I'm not sure I want to bother contributing developers with a whole bunch of plugin sources they care nothing about as part of the main project.
Add the plugin sources into a subfolder of the SVN sources
I think that is a good idea if you don't have too many plugins. You could create a folder structure as shown at the end of my answer in order to manage plugins independently. But in this case you won't have fine control over SVN access.
The advantage is that you only have to maintain one project website (if you create one at all).
Create a separate project for the set of plugins
That's what Notepad++ does, for example. Their plugins are hosted on a separate SourceForge project. Having one download page full of plugins and another download page full of binary releases of your software improves readability. But don't forget to mention on the project web page that there's a separate plugin project.
It also has the advantage that you can manage the project web sites independently. For instance, you could put other users in charge of caring about the plugin site (if you find somebody who wants to maintain them).
Create a seperate project for each individual plugin
Not a good idea, maintenance will be harder this way, as you'll have multiple projects, repositories and project websites.
But it has an advantage though: You can be more fine-grained in granting people access to developing the plugins. For example, users A and B are allowed to work on plugin X, but not on plugin Y. With separate SF projects, this is easy to achieve. Same applies to the project web sites, of course.
So, as a conclusion, I would say that the more you care about SVN access rights and the more plugins you have, the more it makes sense to create one or more separate projects for your plugins.
Example SVN structure from #1:
/modeler
/trunk
/branches
/tags
/modeler-plugins
/plugin-x
/trunk
/branches
/tags
/plugin-y
/trunk
/branches
/tags