Resolving IJJARPATH outside of 3rdpartypublic repository when building from source on Linux

[Pariksheet Nanda]

Fellow developers,

I'm packaging the MM subversion source into a Gentoo Linux ebuild, and
found that configure.in[1] only reads ij jar from the 3rdpartypublic
svn repository.
What is confusing is the AC_MSG_ERROR indicates `with-imagej=path`
would account for ij.jar already installed elsewhere, but for me it
has no effect.  IJJARPATH is not set in configure.common.

Perhaps this functionality is broken?
If so, would it make more sense to run tests and declare (distribution
specific?) IJJARPATH in configure.common while searching for ImageJ
directories, or to test and declare the variable within this
configure.in itself right before the AC_MSG_ERROR like the tests for
beanshell, swingx, etc?

Or is using only the pre-built ij.jar from the 3rdpartypublic
subversion repository intentional, presumably to force a specific
ImageJ version?
In this case, I would like to know the version of ImageJ needed by
Micro-Manager to enforce in the dependency resolution.

The relevant snippet of code from configure.in:

if test "$IMAGEJDIR" != "no" ; then

   #----------------------------------------------------------------
   # Set the CLASSEXT location
   #----------------------------------------------------------------
   CLASSEXT=$PWD"/../3rdpartypublic/classext"
   echo "CLASSEXT="$CLASSEXT

   #----------------------------------------------------------------
   # Find ij.jar in directory
   #----------------------------------------------------------------
   AC_MSG_CHECKING(for ij.jar)
   IJJARDIR="$CLASSEXT/ij.jar"
   echo "IJJARDDIR="$IJJARDIR
   if test -r "$IJJARDIR" ; then
      IJJARPATH="$IJJARDIR"
      AC_MSG_RESULT($IJJARPATH)
   fi

   if test -z "$IJJARPATH"; then
     AC_MSG_ERROR([not found, Use the without-imagej directive to
build without ImageJ or install ImageJ (http://rsb.info.nih.gov/ij/
and rerun configure, possibly using the --with-imagej=path directive])
   fi


Thank you for looking at this,

  --Pariksheet

[1] https://valelab.ucsf.edu/svn/micromanager2/trunk/configure.in

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Nico Stuurman]

Hi Pariksheet,

> I'm packaging the MM subversion source into a Gentoo Linux ebuild, and found that configure.in[1] only reads ij jar from the 3rdpartypublic
> svn repository. What is confusing is the AC_MSG_ERROR indicates `with-imagej=path` would account for ij.jar already installed elsewhere, but for me it has no effect.  IJJARPATH is not set in configure.common.
>
> Perhaps this functionality is broken?

Correct.

> If so, would it make more sense to run tests and declare (distribution specific?) IJJARPATH in configure.common while searching for ImageJ
> directories, or to test and declare the variable within this configure.in itself right before the AC_MSG_ERROR like the tests for
> beanshell, swingx, etc?

There was a somewhat more flexible system (but more laborious to maintain) in place in the past.  We abandoned it when we placed all jars needed to build Micro-Manager in 3rdpartypublic/classext.  The with-imagej=path switch is a remnant of the older system.  

Is there a problem with checking out the 3rdpartypublic repository and letting the conifgure script do its work?

Best,

Nico



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Pariksheet Nanda]

On Tue, Jan 24, 2012 at 3:23 AM, Nico Stuurman <[hidden email]> wrote:
> There was a somewhat more flexible system (but more laborious to maintain) in place in the past.  We abandoned it when we placed all jars needed to build Micro-Manager in 3rdpartypublic/classext.  The with-imagej=path switch is a remnant of the older system.
>
> Is there a problem with checking out the 3rdpartypublic repository and letting the conifgure script do its work?
>

In the short term it would work, but I think a change from using this
would be necessary in the long term.
It's not a problem to use the 3rdpartypublic folder at the minute:
though to get the configure script to work, I would still need to
patch it as fetched micromanager and 3rdpartypublic subversion folders
using Gentoo's eclass cannot reside in a common directory.

My long term goal is to have MM officially supported by Gentoo, which
means having an `ebuild' installation script accepted into Portage,
the main package tree.
Then a user can simply install MM in one command using:

    # emerge micro-manager

There are stricter requirements to get the package accepted in this
main tree (as opposed to fast unofficial methods like creating an
overlay or submitting the ebuild as a bug)

To officially use the 3rdpartypublic repository, there are these issues -

1) Pulling jar binaries instead of the source is discouraged.
http://www.gentoo.org/proj/en/java/why-build-from-source.xml
TBH the above linked reasons are philosophical; and perhaps it may be
accepted into the tree.
The next reason I suspect would be a blocker.

2) It uses subversion, which means it would be masked and thus
unsupported even if it was in the tree.
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html

Another requirement before I can get official Gentoo support is to
have Linux release tarballs, though using a subversion release
snapshot could work in the interim.

I can look into the subversion history of the configure script to see
how it was implemented earlier.

Thanks for your help as always!

> Nico
>

Pariksheet

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Johan Henriksson-2]

On Tue, Jan 24, 2012 at 6:44 AM, Pariksheet Nanda <[hidden email]> wrote:

On Tue, Jan 24, 2012 at 3:23 AM, Nico Stuurman <[hidden email]> wrote:
> There was a somewhat more flexible system (but more laborious to maintain) in place in the past.  We abandoned it when we placed all jars needed to build Micro-Manager in 3rdpartypublic/classext.  The with-imagej=path switch is a remnant of the older system.
>
> Is there a problem with checking out the 3rdpartypublic repository and letting the conifgure script do its work?
>

In the short term it would work, but I think a change from using this
would be necessary in the long term.
It's not a problem to use the 3rdpartypublic folder at the minute:
though to get the configure script to work, I would still need to
patch it as fetched micromanager and 3rdpartypublic subversion folders
using Gentoo's eclass cannot reside in a common directory.

I must say I didn't notice that these flags where dropped. on the other hand, I have seen the old configure script and can see why.
maybe the best way for building on linux, without 3rdparty, is to recreate it creating symlinks to the system library.

1) Pulling jar binaries instead of the source is discouraged.
http://www.gentoo.org/proj/en/java/why-build-from-source.xml
TBH the above linked reasons are philosophical; and perhaps it may be
accepted into the tree.

right, I think this is common
 

The next reason I suspect would be a blocker.

2) It uses subversion, which means it would be masked and thus
unsupported even if it was in the tree.
http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html

Another requirement before I can get official Gentoo support is to
have Linux release tarballs, though using a subversion release
snapshot could work in the interim.

this would actually be a good idea - I have long wanted to synchronize the linux builds with the windows builds. it would make debugging much easier if all platforms used the same release! so if nico et al could just create a tgz/zip (or tar.bz2 to be fancy) of every release, that would be a good starting point.


while at it, to go back to the previous discussion about separating into library, device adapters and GUI - this would allow the secretdeviceadapters to become a its own repository. and thus permissions would not be needed anymore. and we could switch to GIT/HG! this would help tremendously as I can do commits to my own repository until my fixes are ready to be sent back.

/Johan

--
-----------------------------------------------------------
Johan Henriksson
PhD student, Karolinska Institutet
http://mahogny.areta.org  http://www.endrov.net

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Michael Curtis]

On 24/01/2012, at 4:44 PM, Pariksheet Nanda wrote:

> To officially use the 3rdpartypublic repository, there are these issues -
>
> 1) Pulling jar binaries instead of the source is discouraged.
> http://www.gentoo.org/proj/en/java/why-build-from-source.xml
> TBH the above linked reasons are philosophical; and perhaps it may be
> accepted into the tree.
> The next reason I suspect would be a blocker.

One option would be to add all the packages that 3rdpartypublic indirectly uses as depends to the ebuild and then populate the folder at build time (src_unpack or perhaps patch) from the system-wide binaries and Jar files.  This would involve minimal changes (hopefully none) to the MM configure script, but be largely in keeping with the Gentoo spirit.  It's a long time since I messed with ebuilds on Gentoo, but I think Eclipse is one notable ebuild which does something like this (I believe it does or used to copy the ecj Jars from the ecj ebuild / system to a build folder for Eclipse).  



------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Michael Curtis]

On 24/01/2012, at 8:47 PM, Johan Henriksson wrote:

this would actually be a good idea - I have long wanted to synchronize the linux builds with the windows builds. it would make debugging much easier if all platforms used the same release! so if nico et al could just create a tgz/zip (or tar.bz2 to be fancy) of every release, that would be a good starting point.

while at it, to go back to the previous discussion about separating into library, device adapters and GUI - this would allow the secretdeviceadapters to become a its own repository. and thus permissions would not be needed anymore. and we could switch to GIT/HG! this would help tremendously as I can do commits to my own repository until my fixes are ready to be sent back.

With regards to this point, perhaps the MM team could look at cmake for v1.5 or v1.6?  I really like this build tool and it's becoming fairly common (it's fairly easy to install on OS X and Windows and even easier on most modern linuxes).  One of the big advantages is the ability to generate VS project files as well as XCode projects and make files.  This would help to keep the platforms in sync, and in my opinion the syntax is much easier to understand than autoconf.

When I have time (after grants are due...), and the MM project is interested, I'd be happy to donate some time to writing an experimental CMake build script. 

Release tarballs would certainly make things easier for distributions like Gentoo, and potentially could be autogenerated from the SVN tags.

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Pariksheet Nanda]

On Thu, Jan 26, 2012 at 11:26 AM, Michael Curtis
<[hidden email]> wrote:
> One option would be to add all the packages that 3rdpartypublic indirectly
> uses as depends to the ebuild and then populate the folder at build time
> (src_unpack or perhaps patch) from the system-wide binaries and Jar files.
> This would involve minimal changes (hopefully none) to the MM configure
> script, but be largely in keeping with the Gentoo spirit
>

Thanks- this is the approach I'm taking.
ebuilds for all the dependent packages exist, though one requires the
java-overlay.

The MM configure script already looks in 3rdpartypublic and then falls
back to detecting the dependent jar file installed by a package.
So the only change that is needed is to apply this behavior to the
ImageJ dependency as well (which is broken at the minute) by patching
it back to svn r4111 behavior.

I'll attach the full patch once I have the chance to test this late next week.

    #----------------------------------------------------------------
    # Find ij.jar in directory
    #----------------------------------------------------------------
    AC_MSG_CHECKING(for ij.jar)
-   IJJARDIR="$CLASSEXT/ij.jar"
-   echo "IJJARDDIR="$IJJARDIR
-   if test -r "$IJJARDIR" ; then
-      IJJARPATH="$IJJARDIR"
-      AC_MSG_RESULT($IJJARPATH)
-   fi
+   IJJARDIR="$CLASSEXT/ij.jar
+             $IJPATH/ij.jar
+             $IJPATH/ImageJ.app/Contents/Resources/Java/ij.jar
+             $IJPATH/../java/ij.jar"
+
+   for d in $IJJARDIR ; do
+      if test -r "$d" ; then
+         IJJARPATH="$d"
+         AC_MSG_RESULT($IJJARPATH)
+         break
+      fi
+   done

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general