Hello all. There is quite a bit of documentation on building extensions available, but admittedly I’m a novice programmer and am having some trouble understanding a few of the steps and am looking for some guidance.
I have used the extension wizard to build and extension and am in the process of going through the “publishing an extension” checklist" and would like to manually build an extension to test it as documented here.
A. I’m trying to follow the steps listed under " Build your own set of extensions against Slicer trunk build tree" and running into problems. I do not understand the prerequisit "2. Slicer trunk has been checkout into /path/to/Slicer-master and built into /path/to/Slicer-master-SuperBuild-Release
What exactly does this mean? I’m having trouble understanding the goal here.
B. Also, the code block specifies “export SLICER=${HOME}/slicer4/latest/Slicer”… I am working on a mac and the default installation location, I believe, is “export Slicer_DIR=/Users/Applications/Slicer.app”… Is this the appropriate location for this variable, or should it be export “Slicer_DIR=/Users/Applications/Slicer.app/Contents/MacOS/Slicer”? (I think this is an incredibly simple question but I’m having trouble googling it)
C. Is a test manual build really even necessary if I have a .s4ext file “ready” (but not tested) and have otherwise completed the majority of the checklist?
I will likely have more questions but this is probably a fine place to start.
This just means you have a built version of Slicer. It is the same as described at Windows — 3D Slicer documentation. Do you have a built version of Slicer already? Based on your “B)” section I’m thinking not. Is your extension C++ based modules or python based modules?
There is also another documentation section about building an individual extension Documentation/Nightly/Developers/FAQ/Extensions - Slicer Wiki. This is a little different than building the Slicer extensions index which can build a set of extensions.
It is of course good to test building your extension otherwise your extension might fail and then won’t show up as an option to distribute if you choose to submit to the Slicer Extensions Index. Generally the .s4ext is less necessary to test directly since it is fairly simple formatting, but the appropriate building of your extension (the CMakeLists.txt and supporting files) is what is more important and the more likely area where issues occur.
What method have you been using to install/use the modules of your extension in Slicer during your development period?
Thanks for the reply! My extension is a python based module. Thanks for highlighting the difference between needing to build an extension index and simply creating an extension.
I used the ExtensionWizard to create the basic code and mostly copied from a variety of other example extensions that had somewhat similar code to what I was trying to do. I’ve successfully downloaded the zipped folder from my github page and imported it. If my extension builds properly being imported through the ExtensionWizard is it reasonable to assume that it will “build properly” if the s4ext file works?
I’ve honestly never tried installing an extension through the ExtensionsManager using the GitHub downloaded zip file. I typically always build the extension using a Slicer build tree which then creates the zip package.
It sounds like you’re following the extension development process well and doing the extension checklist. So I would suggest you go ahead and submit the PR to the slicer extensions index. I could try building it like how the factory build machine will do it, once you have that PR up and I can see where your extension is located.
https://github.com/Slicer/ExtensionsIndex/pull/1750 Is correct . Everyone struggles a bit to learn the GitHub upstream/fork workflows, but you’ll learn over time. The slicer developers will likely review your extension PR in the upcoming week or so and once merged then it will be distributed through the Slicer Extensions Manager, but until then others can manually build and install or specify the files as additional modules to load.
. Everyone struggles a bit to learn the GitHub upstream/fork workflows, but you’ll learn over time. The slicer developers will likely review your extension PR in the upcoming week or so and once merged then it will be distributed through the Slicer Extensions Manager, but until then others can manually build and install or specify the files as additional modules to load.