Changing the SDK

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Changing the SDK

Kip Streithorst
Administrator
All,

In switching to CMake, by default it will not create the existing
Build\Binaries-XX-YY-debug\Bin, \Lib, \PlugIns directories that we
currently use in both Opticks and SDK.  I can certainly make it use that
layout, but since we have switched to Ivy, it could be useful to publish
the SDK into the same directory structure we use for the other 3rd-party
dependencies.

That directory structure is:

\32\lib
\32\include
\64\lib
\64\include

This is also the directory structure that CMake prefers.

So, I'm proposing the following changes to layout/naming of the libs and
includes:

Example on Windows:
\32\lib\OpticksPlugInLib.lib
\32\lib\OpticksPlugInLibd.lib
\32\include\opticks\
                    Interfaces
                    PlugInLib
                    HdfPlugInLib

Example on Linux/Solaris:
\32\lib\libOpticksPlugInLib.a - either release or debug, only one at a
time (this is consistent with these platforms)
\32\include\opticks\
                    Interfaces
                    PlugInLib
                    HdfPlugInLib

In summary:
1) Adding the name opticks to our existing libs to avoid collisions with
libs from 3rd parties
2) Putting includes under an Opticks directory.  This would permit us in
the future to start using #include "opticks/". I'm not suggesting that
at the moment.
3) Appending a "d" suffix to the names of the debug libs on Windows.
This allows the debug and release libs to live in one directory and is
consist with other 3rd party libraries on Windows.

There is also a question of how distribute the SDK. Should we only
distribute the Ivy dependency management system and then when it is run
it will download and extract the SDK?  Should we only distribute a
standalone zip file that contains a copy of the Ivy dependency
management, but Ivy is only used to download and extract 3rd party
dependencies (e.g. what we are currently doing in 4.6.X and 4.7.X)?
Should we attempt to do both (I worry this could be more confusing than
helpful)?

There are other questions that come out of this discussion.

Should we include the binaries (Opticks.exe and plug-in dlls) in the SDK
(We don't currently on Windows and Solaris)?  If not, how should we
distribute them (We could make a MSI installer on Windows with the debug
Windows binaries)?

Should the sample code and tutorials be in the SDK?  Should the binaries
for the sample code be in the SDK (they could be packaged into an AEB)?
One could argue that it would be more illustrative to have the sample
code separate from the SDK so that it shows developers how to locate the
SDK and Opticks binaries.

Looking to start the discussion on all this stuff early. If you have
other things you like or dislike about the current SDK, let us know.

Looking forward to your thoughts and feedback.

Thanks,
Kip




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Opticks-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opticks-devs