Setting up Xcode for developing Plug-ins - objective-c

I've never worked in XCode before but I am designing a plugin (objective-c) for an open source radiology program called OsiriX. I can get the thing to compile and I can even get the plugin to run in OsiriX. But, I'm not sure how to run/debug it from XCode. Run/Debug is grayed out on my xcode. Is it because there's no main program?

(1) "Clean all" your projects so that there isn't detritus left around when you do this.
(2) Set Xcode to use a common build products directory (I stick mine in /tmp/ so that it periodically gets nuked). The preference is under the "Building" section.
(3) Re-build OsiriX (so that it'll be built in the shared location).
(4) Make sure the active configuration in your plug-in project has the exact same name as the configuration in OsiriX that you built in (3). (It should probably be "Debug" or "Release", depending on which you build). The configurations can be edited in the build settings editor.
(5) Build your plug-in.
(6) Add a custom executable to your plug-in project and set the path to OsiriX (Project -> New Custom Executable...).
You should now be able to build-and-run or build-and-debug your project. It will launch OsiriX from the build products directory. You might also want to set OsiriX to look for bundles in your build products directory, if it doesn't already. Or you could create a symbolic link from one of OsiriX's plug-in directories to the bundle in your build products directory.
cd /path/to/OsiriX's/bundle/directory
ln -s /path/to/build/products/YourPlugin.bundle
This is a very standard way of ocnfiguring Xcode for development of plug-ins. For example, preference pane developers will set up a custom executable for SystemPreferences.app (even in /Applications -- there is no need to point to a "debug" build of the application).

In order to debug your plugin, you have to be running Osirix in Xcode as well. Download the Osirix source code from Github and compile and run it. You'll have to add the plugin to its plugin list and then when you run in Xcode your NSLog statements from the plugin source will print out in the Xcode console screen for the main Osirix program. I believe breakpoints work as well.

My experience with Xcode is also somewhat limited, but I've found that using the latest version (6.1.1) I can debug my plugin simply by attaching to a running OsiriX process via the Debug -> Attach Process menu. This does not require you to build OsiriX from source - I'm currently using the standard (non-MD) version as downloaded from their website.
Note that you still need to restart OsiriX to pick up any changes to your plugin.

Related

Ksp multiplatform redeclaration of files

I am implementing ksp processor in kotlin multiplatform targeting iOS and android applications, following documentation I'm defining multiple configuration names for KSP ie:
add("kspIosArm64", project(":test-processor"))
add("kspIosX64", project(":test-processor"))
However running those gives me file redeclaration error. Indeed files are created in separate locations:
build/generated/ksp/iosArm64/ and build/generated/ksp/iosX64/ but packages are the same.
And Im quite lost how to solve this issue, is there any way of getting this generated folder path for each generated file so that package can be modified?
I will try to partially answer your questions right now, not to make you stack and focus on making the project able to run. I assume that you are using XCode to run the project for iOS. The problem here is that (as you mentioned) all of those source sets are being generated with the same package name which is more a KSP issue (I think) that we have to wait for to be solved.
What you can do for now to run and test the project is:
Make sure to clean your build with ./gradlew clean before running the project (especially between Android and iOS runs)
I think clean can be added as a "step" before KMM framework task:
XCode Project file -> Build Phases -> Generate KMM framework -> add clean before running gradle task responsible for building framework (This can will make build time longer)
./gradlew :yourSharedModule:clean :yourSharedModuleName:embedAndSignAppleFrameworkForXcode
Selected only one architecture to be build when running the project
XCode Project -> Build Settings -> Architectures -> Build Active Architecture Only -> Yes
This solutions makes only one architecture to be build and run (it is probably a simulator in your case), issue here is you may have some problems with other architectures and will not be able to spot them easily on daily development.
Create some kind of env or a build config value to distinguish which ksp dependency to add (based on it's value) so not all of processors are added when running the project
XCode Project -> Build Phases -> Generate KMM framework -> pass it as gradle param -Parchitecture=someArchitecture
Or maybe it is even possible to do it within the build.gradle.kts file
Manually comment out some of ksp dependencies (iOS ones) so the only one against which you are building is left (remember to sync project and clean it)
I personally would try to implement the third solution, I do not know whether it is easy, but it seems to be the best one, other solutions should also work, but please consider them as a dirty walk-around.
I can provide more info or some kind of POC for that later, just let me know in the comments or somewhere else whether it is needed.

Clion Remote - Is it possible to create a Remote Toolchain and apply it to a Project?

I am following the Clion Blog article: Stay Local, let your IDE do remote work for you
Under the heading, "How to configure a remote project in Clion?" I'm told: first of all go to settings/preferences / Build, Execution, Deployment / Toolchains: Create a new Toolchain
So, I'm guessing the author is suggesting that 'first' I can go to the toolchains dialog and create a 'remote toolchain' with ssh settings and so forth.
However, Clion does not seem to enable access to the Toolchains configuration unless I already have a project.
So is this a problem of my expectations for accurate precision being too high, or is there actually a way to create a toolchain configuration without first creating a project to associate the toolchain configuration with?
Also, after creating a toolchain configuration associated with a project, how can I associate that toolchain with other projects, as other areas of the bloc seem to say is possible?
Thanks,
Stato Machino
However, Clion does not seem to enable access to the Toolchains configuration unless I already have a project.
Hi Stato. You can configure your toolchain from Welcome screen or on IDE first running without opening any project.
Also, after creating a toolchain configuration associated with a project, how can I associate that toolchain with other projects, as other areas of the bloc seem to say is possible?
When you create CMake project or opening existing one CLion creates new profile with Default toolchain. Default is just a first toolchain in the list. So simply moving Remote toolchain to the top in Preferences | Build, Execution, Deployment | Toolchains will automatically switch all your project to remote mode.

How to properly import a Play 2+ project in IntelliJ 14+ with all integrated features (run, debug, test)?

I work on a Java based Play! project for severals months now and I'd like to import it completely in IntelliJ, meaning being able to run, compile, test and debug from IntelliJ, without the need to use the command line.
According to this post from Jetbrain, it seems to be possible, if I quote the article it says clearly : "Now you don’t need to switch between IntelliJ IDEA and Play console anymore. Everything is available right from your favorite IDE.", but I can't figure out a way to achieve this for now, even if I follow the tutorial provided by Jetbrains.
Here are the steps I've been throught :
Open my fav IDE IntelliJ ;)
Go to the project list window.
Import project
Import from external model and choose SBT as suggested in Jetbrains tutorial.
option "Use auto import" checked, option "create directories for empty content roots automatically" checked. Project SDK Java 1.7
Global sbt settings : JVM From project JDK.
Finish
By now, if I try to make the project and launch it from IntelliJ, I'll get scala compiling errors related to routes object. Thanks to this post, we can understand that this happens because scala routes are located to specific folders that needs to be included in IntelliJ sources settings for this project. So next step was :
File -> Project Structure -> Modules
Add target/scala-2.10/classes:target/scala-2.10/resources_managed:target/scala-2.10/src_managed as sources folders.
But my problem remains the same, routes object being unrecognized.
Notes : I have no scala facets in my project structure configuration nor can add one.
IntelliJ provides integrated support for the Play Framework for Scala and Java. Support is currently only available in IntelliJ Ultimate Edition (see the Frameworks and Technology section).
Assuming Ultimate Edition, the setup for Play is incredibly easy. Simply create a new project by importing build.sbt, then choose Add Framework Support and choose Play 2.
Once complete, you can start and stop Play using the Play 2 Run/Debug configuration. No command line necessary.
Here is a more in depth look at IntelliJ's Play project configuration.
You could try the command play idea if you are using play or activator idea if you are using activator. That will do the magic.

Can't get Changes tool window (Alt+9) to show on IntelliJ IDEA

I can't get the Changes tool window to show on this project.
The project is imported "from sources" and has no facet and no sdk. Which is ok because I'm only editing it in the IDE and running from the terminal.
I'm on Windows 8.
The tool window does show when I open another java web maven project there.
It also does show for the first (no sdk) project when I'm on Ubuntu.
What might the Changes tool window not like about my project?
The IDE wasn't aware of Git in my project.
That happened because the directory I import this project from isn't the same as the Git repository directory, the former is inside the later.
I fixed it in: VCS > Enable Version Control Integration

How do you link an eclipse project to an eclipse plug-in project?

I am building an eclipse plug-in project that acts as a front end. I also have a separate eclipse project that runs as a backend. Right now I can run each of them separately and they communicate just fine using sockets.
I would like the plug-in to create the major components of the back end when it starts but also keep the two projects separate so that I can use other editors to communicate with the back end. So, I added the back end eclipse project to the build properties of the plug-in project and I added some code from the back end driver to the plug-in activator's start(). However, when I run the plug-in project I am getting class not found exceptions for all back end references. It appears to compile fine, but I can't run it. I do not do anything to the MANIFEST.MF file in the plug-in project.
How does one add a second java project to an eclipse plug-in project?
There are several ways you can do this, going from best and most difficult to worst and easiest:
(1) Use a build tool (such as the built-in ANT, or tycho, or (as I'm sure there are) some other). This is by far the best solution, but is quite a bit more involved than the next 2.
(2) Convert your non-plugin project to a plugin project and add it as a plugin dependency in your plugin settings file's dependencies tab
(3) Export your non-plugin to a new .jar in your plugin project directory (e.g. $project_loc/lib/something.jar); go into plugin settings (plugin.xml) and include it in: The Build tab under binary build, and the Runtime tab under Classpath. (Or edit the corresponding entries in manifest.mf and build.properties)
For most cases I'd recommend approach (1); look up a few tutorials online, there are plenty. (3) is the quick-and-dirty non-flexible workaround to your particular situation, good for nothing other than seeing if it actually can run. (2) is somewhere in between -- obviously not ideal, but not as bad as 3.