Patches to simplify Unix builds

[Erich E. Hoover]

I feel like the Unix build process is a little over-complicated and it makes it difficult to build device adapters outside of the Micro-Manager tree.  Attached are some patches that I would suggest to make the process run a little smoother.

1) Change Unix library inclusion to require the suffix (".so.0"), allowing device adapters to be auto-installed by libtool.
2) Add defines for MMDEVAPI_CXXFLAGS and MMDEVAPI_LIBADD for use by the automake scripts.
3) Change the automake scripts to utilize the new defines and automatically install and uninstall device adapters with libtool*.
4) Install the static libMMDevice.a library to the system library folder.

These changes allow custom device adapters to be built more easily from outside of the tree, allow for the easy installation and uninstallation of the device adapters, and permit the device adapters to include the Micro-Manager headers like so:
#include <MMDevice/ModuleInterface.h>
instead of using the relative path:
#include "../../MMDevice/ModuleInterface.h"

I think these changes would really help the build process, so I hope you find them to your liking!

Erich Hoover
[hidden email]

* The install routine is not changed for SimpleCam, since the procedure is a little more complicated than the other adapters.

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Nico Stuurman]

Hi Erich,

 

On Jan 5, 2012, at 11:46 AM, Erich E. Hoover wrote:

I feel like the Unix build process is a little over-complicated and it makes it difficult to build device adapters outside of the Micro-Manager tree. 

Thanks for your work on this!  

Why do you want to build the device adapters outside of the Micro-Manager tree?  We set everything up to build a self-contained application (and we are focussed on Mac and Windows), and there never is a need to work outside of the tree for that, so it would help to understand how you would like to work with the code.

Also, it would be helpful to know if others (working on linux) would like to see these changes in the build process as well.  I do expect that these changes will cause problems in various scenarios (the multi-architecture build on the Mac being on of them) and it will be quite a bit of work to implement, so I do need to be convinced that it is useful to a reasonable number of people before fully committing to it.

Attached are some patches that I would suggest to make the process run a little smoother.

1) Change Unix library inclusion to require the suffix (".so.0"), allowing device adapters to be auto-installed by libtool.

Why do you want libtool to take care of installation?  Personally, I do not like the ".so.0" extension very much, it looks very geeky.  Also, on the Mac, loadable modules do not need any particular extension (although Apple recommends ".bundle").  I am quite reluctant to force a naming convention just to use libtool (which is in part 

Also, how does libtool decide where to install the adapters?  Does that work with the configure -- install prefix?  If so, does libtool insist on putting them into a 'lib' subdirectory?

2) Add defines for MMDEVAPI_CXXFLAGS and MMDEVAPI_LIBADD for use by the automake scripts.

Nice!

3) Change the automake scripts to utilize the new defines and automatically install and uninstall device adapters with libtool*.
4) Install the static libMMDevice.a library to the system library folder.

That kind of goes against the whole idea behind our build process.  Why spread out all files over the whole system?  It is much more convenient and maintainable to keep everything needed for the application in the application's directory.  This may not be true for other applications and libraries, but in our case, life gets a whole lot simpler if we can isolate it to a specific area.  So, I would never want libMMDevice.a to go to a system library folder (and deal with different versions and what not), but rather keep it local.  

These changes allow custom device adapters to be built more easily from outside of the tree

Again, what is against developing that custom adapter inside the Micro-Manager tree?  The whole system has been set up this way (for instance, see: http://valelab.ucsf.edu/~MM/MMwiki/index.php/Building_Micro-Manager_Device_Adapters ), and changing it is most likely going to break many things (and take many, many hours of work).

allow for the easy installation and uninstallation of the device adapters, and permit the device adapters to include the Micro-Manager headers like so:
#include <MMDevice/ModuleInterface.h>
instead of using the relative path:
#include "../../MMDevice/ModuleInterface.h"

I think these changes would really help the build process, so I hope you find them to your liking!

Best,

Nico

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Johan Henriksson-2]

On Thu, Jan 5, 2012 at 8:46 PM, Erich E. Hoover <[hidden email]> wrote:

I feel like the Unix build process is a little over-complicated and it makes it difficult to build device adapters outside of the Micro-Manager tree.  Attached are some patches that I would suggest to make the process run a little smoother.

I agree with you. my wet dream would be to have micromanager split into
* a pure core library, with all java code not specific for imagej
* a driver library, depending on the core. this would give you the separation you want, and it would make it easier for third parties to ship drivers (in particular, stupid binary blobs). I think I also would be happy if I could prototype drivers in my own GIT repo separate from the main tree
* the user interface with imagej. this could, as far as I am concerned, contain all the windows and osx-specific clutter for installation

I have some trouble applying the patches. what command do you people use?
 

1) Change Unix library inclusion to require the suffix (".so.0"), allowing device adapters to be auto-installed by libtool.

nice. this should take the make install closer to the debian package
 

2) Add defines for MMDEVAPI_CXXFLAGS and MMDEVAPI_LIBADD for use by the automake scripts.
3) Change the automake scripts to utilize the new defines and automatically install and uninstall device adapters with libtool*.

good stuff!
 

4) Install the static libMMDevice.a library to the system library folder.

I have always just used /usr/lib/micro-manager/libMMCoreJ_wrap.so.

is there a need for a static library and what are the technical implications? I don't see how java+JNI could benefit and the linking issues are making my head explode...

/Johan




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

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Nico Stuurman]

On Jan 6, 2012, at 7:36 AM, Johan Henriksson wrote:

On Thu, Jan 5, 2012 at 8:46 PM, Erich E. Hoover <[hidden email]> wrote:

I feel like the Unix build process is a little over-complicated and it makes it difficult to build device adapters outside of the Micro-Manager tree.  Attached are some patches that I would suggest to make the process run a little smoother.

I agree with you. my wet dream would be to have micromanager split into
* a pure core library, with all java code not specific for imagej

This nomenclature is a bit confusing.  Micro-Manager has a "Core", written in C++ that dynamically loads device adapters.  I think that you would like the Java GUI code to be split up into an ImageJ independent (which you call "core") and ImageJ dependent part. Big task (and not high on our priority list).  

* a driver library, depending on the core. this would give you the separation you want, and it would make it easier for third parties to ship drivers (in particular, stupid binary blobs). I think I also would be happy if I could prototype drivers in my own GIT repo separate from the main tree

How is this different from the current implementation (Core that loads device adapters dynamically at run-time)?  Nothing stops you from building the device adapters somewhere else (you just have to adjust the paths).  Third parties can (and do!) ship device adapters as binary blobs (but ensuring that versions of Core and device adapters match is hard, so life is much easier if the device adapter lives in the Micro-Manager repository).

4) Install the static libMMDevice.a library to the system library folder.

I have always just used /usr/lib/micro-manager/libMMCoreJ_wrap.so.

That is a different beast.  libMMDevice.a is a convenience library used by the device adapters to interface to the "lower" API of the Core (i.e. the device adapters link the common code in MMDevice statically through libMMDevice.a, on Windows, we actually compile the code again for each device adapter to avoid nasty linking issues).  libMMCoreJ_wrap.so contains the "upper" API, the device abstraction that is called from user interface code.  See: <a href="http://valelab.ucsf.edu/~MM/MMwiki/index.php/Micro-Manager Project Overview">http://valelab.ucsf.edu/~MM/MMwiki/index.php/Micro-Manager%20Project%20Overview and look for the block-diagram of the software architecture.

Best,

Nico

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Johannes Schindelin]

Hi,

On Fri, 6 Jan 2012, Nico Stuurman wrote:

> On Jan 6, 2012, at 7:36 AM, Johan Henriksson wrote:
>
> > On Thu, Jan 5, 2012 at 8:46 PM, Erich E. Hoover <[hidden email]> wrote:
> > I feel like the Unix build process is a little over-complicated and it
> > makes it difficult to build device adapters outside of the
> > Micro-Manager tree.  Attached are some patches that I would suggest to
> > make the process run a little smoother.
> >
> > I agree with you. my wet dream would be to have micromanager split into
> > * a pure core library, with all java code not specific for imagej
>
> This nomenclature is a bit confusing.  Micro-Manager has a "Core",
> written in C++ that dynamically loads device adapters.  I think that you
> would like the Java GUI code to be split up into an ImageJ independent
> (which you call "core") and ImageJ dependent part. Big task (and not
> high on our priority list).  

I might be able to help with this, once I finished some work on Fiji and
ImageJ2. My idea is to "port" uManager to IJ2 and while at it abstract
things enough so that Endrov could provide a little glue code and use
uManager without changes. Although the better idea would be to port Endrov
to the IJ2 architecture anyway.

Ciao,
Dscho

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Johan Henriksson-2]

I agree with you. my wet dream would be to have micromanager split into
* a pure core library, with all java code not specific for imagej

This nomenclature is a bit confusing.  Micro-Manager has a "Core", written in C++ that dynamically loads device adapters.  I think that you would like the Java GUI code to be split up into an ImageJ independent (which you call "core") and ImageJ dependent part. Big task (and not high on our priority list).  

ah, sorry, you're right. the separation is entirely on the build level and suddenly putting libMMDevice.a in the system library makes sense to me! (christmas made me stupid)
this brings the micromanager core closer to a being library with clear separation of the dependencies, like all libraries, and GUI and driver development can be done in separate projects (in the build sense).

* a driver library, depending on the core. this would give you the separation you want, and it would make it easier for third parties to ship drivers (in particular, stupid binary blobs). I think I also would be happy if I could prototype drivers in my own GIT repo separate from the main tree

How is this different from the current implementation (Core that loads device adapters dynamically at run-time)?  Nothing stops you from building the device adapters somewhere else (you just have to adjust the paths).  Third parties can (and do!) ship device adapters as binary blobs (but ensuring that versions of Core and device adapters match is hard, so life is much easier if the device adapter lives in the Micro-Manager repository).

indeed this separation might be overzealous. however, it may have advantages for distribution. I think a big reason why the micromanager build system is so complicated at the moment, is that is so closely entangles compilation with distribution. that's an inherent problem of the developer tools though.

 

schindelin: I and curtis have previously discussed bringing endrov and IJ2 closer. it is likely going to happen, though not before I defend my thesis

/Johan


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

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[John Oreopoulos]

Hi all,

I'm wondering if there is any way to change the pixel clock rate on a Hamamatsu ImageEM EMCCD camera (C9100-13). The spec sheet says there are three different rates (11 MHz, 2.75 MHz, and 0.69 MHz) available. I do not see this as a device property in the MicroManager device property manager (neither in the Read-only properties). Furthermore, I can't figure out how to make this change using the native DCAMAPI software that comes with the camera. Can anyone out there help me with this?

Thanks!

John Oreopoulos




------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Erich E. Hoover]

On Thu, Jan 5, 2012 at 11:33 PM, Nico Stuurman <[hidden email]> wrote:

On Jan 5, 2012, at 11:46 AM, Erich E. Hoover wrote:

I feel like the Unix build process is a little over-complicated and it makes it difficult to build device adapters outside of the Micro-Manager tree. 

...

Why do you want to build the device adapters outside of the Micro-Manager tree?  We set everything up to build a self-contained application (and we are focussed on Mac and Windows), and there never is a need to work outside of the tree for that, so it would help to understand how you would like to work with the code.

I have my own adapter that I've built for some in-house electronics and it's easier for me to build and package it against different versions of MM if it's outside of the tree.  We're working on spreading our imaging technology to other groups, at which point it might be appropriate to get it included in MM, but for now it makes more sense for me to build against two separate targets (subversion for me and the latest stable release for everyone else in the lab).

...

Attached are some patches that I would suggest to make the process run a little smoother.
1) Change Unix library inclusion to require the suffix (".so.0"), allowing device adapters to be auto-installed by libtool.

Why do you want libtool to take care of installation?  Personally, I do not like the ".so.0" extension very much, it looks very geeky.  Also, on the Mac, loadable modules do not need any particular extension (although Apple recommends ".bundle").  I am quite reluctant to force a naming convention just to use libtool (which is in part 

Because libtool's installation process works cleaner than "manually" installing packages, particularly when performing "make uninstall" or doing dependencies.  Technically the patch uses "LIB_NAME_SUFFIX", which is only going to force a suffix match on Linux.

Also, how does libtool decide where to install the adapters?  Does that work with the configure -- install prefix?  If so, does libtool insist on putting them into a 'lib' subdirectory?

When used "normally" (lib_LTLIBRARIES) libtool installs to the folder "$libdir" ("$prefix/lib/").  However, when used with the "package" mode (pkglib_LTLIBRARIES) the default is "$libdir/@PACKAGE@/".  I do recognize that you don't want to install the files in this manner on all systems.  So in the case of the supplied patch (part 3), this behavior was overridden by changing "pkglibdir" to force the installation path to the same folder you were manually installing to before:
pkglibdir = $(DESTDIR)$(DEVICEADAPTERPATH)

There's a little about about this in the automake manual:
http://www.gnu.org/software/automake/manual/html_node/Libtool-Libraries.html

The one thing I don't know for sure, that's related to this, is what extension you're using on Mac.  It appears that you're actually stripping the extension off on Mac, if that's the case then it is also necessary to add this to the LDFLAGS (and run "make clean" if there are existing files):
-shrext "$(MMSUFFIX)"

That way the installation will create libraries with no extension on the Mac and ".so" on Linux.  I can easily update the patch to add this if you'd like.

...

3) Change the automake scripts to utilize the new defines and automatically install and uninstall device adapters with libtool*.
4) Install the static libMMDevice.a library to the system library folder.

That kind of goes against the whole idea behind our build process.  Why spread out all files over the whole system?  It is much more convenient and maintainable to keep everything needed for the application in the application's directory.  This may not be true for other applications and libraries, but in our case, life gets a whole lot simpler if we can isolate it to a specific area.  So, I would never want libMMDevice.a to go to a system library folder (and deal with different versions and what not), but rather keep it local.

Well, I would like to be able to build my adapters outside of the tree for the reason I discussed.  Maybe this could only happen on Linux or be a special configuration option?

These changes allow custom device adapters to be built more easily from outside of the tree

Again, what is against developing that custom adapter inside the Micro-Manager tree?  The whole system has been set up this way (for instance, see: http://valelab.ucsf.edu/~MM/MMwiki/index.php/Building_Micro-Manager_Device_Adapters ), and changing it is most likely going to break many things (and take many, many hours of work).

I made these patches in such a way that, to the best of my knowledge, they should not break the build.  The build works very differently on Linux than it does on Windows and Mac and it currently doesn't fit well within either the "single-package" or the "traditional Linux system install" paradigm.  Transitioning over to using libtool's installation features would actually make it easier to do things like make a "single-package" Linux build or strip the ".so" extension off the adapters, if that's something you're interested in doing.  Also, I would be willing to help with any bugs that arise from these patches.  This is not something that I could have done last semester, which is why I've waited until now to submit.

Erich Hoover
[hidden email]

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Johannes Schindelin]

Hi Erich,

On Fri, 6 Jan 2012, Erich E. Hoover wrote:

> On Thu, Jan 5, 2012 at 11:33 PM, Nico Stuurman <[hidden email]> wrote:
>
> > On Jan 5, 2012, at 11:46 AM, Erich E. Hoover wrote:
> >
> > I feel like the Unix build process is a little over-complicated and it
> > makes it difficult to build device adapters outside of the
> > Micro-Manager tree.
> >
> > ...
> > Why do you want to build the device adapters outside of the
> > Micro-Manager tree?  We set everything up to build a self-contained
> > application (and we are focussed on Mac and Windows), and there never
> > is a need to work outside of the tree for that, so it would help to
> > understand how you would like to work with the code.
> >
>
> I have my own adapter that I've built for some in-house electronics and
> it's easier for me to build and package it against different versions of
> MM if it's outside of the tree.  We're working on spreading our imaging
> technology to other groups, at which point it might be appropriate to
> get it included in MM, but for now it makes more sense for me to build
> against two separate targets (subversion for me and the latest stable
> release for everyone else in the lab).

I have a similar situation, except that I use Fiji's recently acquired
feature to have multiple update sites to offer uManager including the
relevant drivers via that updating mechanism. That way, I can build
in-tree and once the paper is published, will try to convince the good
uManager team to merge my driver (which will be easier because it is
in-tree already).

Ciao,
Johannes

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Nico Stuurman]

Hi Erich,

> The one thing I don't know for sure, that's related to this, is what extension you're using on Mac.  It appears that you're actually stripping the extension off on Mac, if that's the case then it is also necessary to add this to the LDFLAGS (and run "make clean" if there are existing files):
> -shrext "$(MMSUFFIX)"
>
> That way the installation will create libraries with no extension on the Mac and ".so" on Linux.  I can easily update the patch to add this if you'd like.

Could you please do so?  I'll then apply the patches and see what happens to my build;)

Thanks!

Nico


------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Erich E. Hoover]

On Mon, Jan 9, 2012 at 12:50 PM, Nico Stuurman <[hidden email]> wrote:

Hi Erich,

> The one thing I don't know for sure, that's related to this, is what extension you're using on Mac.  It appears that you're actually stripping the extension off on Mac, if that's the case then it is also necessary to add this to the LDFLAGS (and run "make clean" if there are existing files):
> -shrext "$(MMSUFFIX)"
>
> That way the installation will create libraries with no extension on the Mac and ".so" on Linux.  I can easily update the patch to add this if you'd like.

Could you please do so?  I'll then apply the patches and see what happens to my build;)

Ok, the attached patches supersede those from the original email.  I decided to tweak the patches a bit to make it easier to change the LDFLAGS for everything (MMDEVAPI_LDFLAGS) and added the "-shared" flag, since there is no need for the static library.  I also updated the first patch to require no extension on the Mac, since otherwise MM might attempt to link against the ".la", ".0", and ".0.0.0" files (though these may not even be created on Mac).

Erich Hoover
[hidden email]

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Erich E. Hoover]

On Mon, Jan 9, 2012 at 3:00 PM, Erich E. Hoover <[hidden email]> wrote:
> ...
> Ok, the attached patches supersede those from the original email.  I decided to tweak the patches a bit to make it easier to change the LDFLAGS for everything (MMDEVAPI_LDFLAGS) and added the "-shared" flag, since there is no need for the static library.  I also updated the first patch to require no extension on the Mac, since otherwise MM might attempt to link against the ".la", ".0", and ".0.0.0" files (though these may not even be created on Mac).

Whoops, I just realized that I had a typo in what I had uploaded (a
missing "escape" slash).  I also added the "-avoid-version" flag,
since this project clearly does not require specific interface version
files (the extra ".0" and ".0.0.0" files).

Erich Hoover
[hidden email]

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

[Erich E. Hoover]

On Mon, Jan 9, 2012 at 6:24 PM, Erich E. Hoover <[hidden email]> wrote:
> On Mon, Jan 9, 2012 at 3:00 PM, Erich E. Hoover <[hidden email]> wrote:
> > ...
> > Ok, the attached patches supersede those from the original email.  I decided to tweak the patches a bit to make it easier to change the LDFLAGS for everything (MMDEVAPI_LDFLAGS) and added the "-shared" flag, since there is no need for the static library.  I also updated the first patch to require no extension on the Mac, since otherwise MM might attempt to link against the ".la", ".0", and ".0.0.0" files (though these may not even be created on Mac).
>
> Whoops, I just realized that I had a typo in what I had uploaded (a
> missing "escape" slash).  I also added the "-avoid-version" flag,
> since this project clearly does not require specific interface version
> files (the extra ".0" and ".0.0.0" files).

Bah, sorry for the repeated replies here.  I forgot to check that the
patch worked with DESTDIR being set (this value is automatically
pre-pended to pkglibdir), attached is an updated patch 3.  This
version also hits the LudlLow makefile, which recently reappeared
(diff is against svn 8461).

Erich Hoover
[hidden email]

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general