On Jul 22, 2010, at 4:09 AM, Jerry wrote:
>
> On Jul 13, 2010, at 10:52 AM, Alan W. Irwin wrote:
>
>> On 2010-07-13 09:47-0600 Orion Poplawski wrote:
>>
>>> On 07/13/2010 01:21 AM, Alan W. Irwin wrote:
>>>> I think very little effort would be required to remove
>>>> HAVE_ADA_2007
>>>> from the build system. However, let's wait to do anything about
>>>> this
>>>> until we understand the linking issue that Orion reported a lot
>>>> more.
>>>> I still think the linking issue may be completely orthogonal to
>>>> HAVE_ADA_2007. You imply above, that lapack/blas are not used by
>>>> HAVE_ADA_2007 so it appears to me that Orion's discovery of a
>>>> lapack/blas linking issue must be completely independent of
>>>> HAVE_ADA_2007.
>>>
>>> Nope, if I turn HAVE_ADA_2007 off, it compiles fine.
>>
>> Thanks, Orion, for that clarification.
>>
>> The rest of this is principally directed to Jerry.
>>
>> Jerry, given that clarification does that firm up your idea of
>> removing HAVE_ADA_2007 because the benefit is rather small for the
>> cost of the the extra lapack/blas dependencies?
>>
>> The rest of this assumes you want to make that change.
>> As far as the build system is concerned, all you have to
>> do to completely disable HAVE_ADA_2007 is to replace
>>
>> option(HAVE_ADA_2007 "Ada 2007?" OFF)
>>
>> with
>>
>> set(HAVE_ADA_2007 OFF CACHE BOOL "Ada 2007?" FORCE)
>>
>> in cmake/modules/ada.cmake. The effect of that last command is to
>> force
>> the OFF value regardless of what the user attempts to set.
>> After that, at your leisure, you can remove any HAVE_ADA_2007
>> configuration dependencies in the bindings and examples and also
>> in the build system.
>>
>> To help you with that effort, here are the current places where
>> HAVE_ADA_2007 shows up in our source tree.
>>
>> softw...@raven> find -type f |grep -v .svn| \
>> grep -v '~$' |xargs grep -l HAVE_ADA_2007
>> ./doc/docbook/src/ada.xml
>> ./bindings/ada/README.rtf
>> ./bindings/ada/README
>> ./cmake/modules/ada.cmake
>>
>> All of those except ada.cmake are documentation. Looking at that
>> file further, it sets Ada_Is_2007_With_and_Use_Numerics if
>> HAVE_ADA_2007
>> is ON, and Ada_Is_Not_2007_Vector_Matrix_Declarations otherwise.
>>
>> Those variables show up in the following places in our source tree :
>>
>> softw...@raven> find -type f | grep -v .svn | grep -v '~$' | \
>> xargs grep -l Ada_Is_2007_With_and_Use_Numerics |sort
>> ./bindings/ada/plplot.adb.cmake
>> ./bindings/ada/plplot.ads.cmake
>> ./bindings/ada/plplot_auxiliary.ads.cmake
>> ./bindings/ada/plplot_thin.ads.cmake
>> ./bindings/ada/plplot_traditional.adb.cmake
>> ./bindings/ada/plplot_traditional.ads.cmake
>> ./cmake/modules/ada.cmake
>> ./examples/ada/x01a.adb.cmake
>> ....
>> ./examples/ada/x31a.adb.cmake
>> ./examples/ada/xthick01a.adb.cmake
>> ....
>> ./examples/ada/xthick31a.adb.cmake
>>
>> softw...@raven> find -type f | grep -v .svn | grep -v '~$' | \
>> xargs grep -l Ada_Is_Not_2007_Vector_Matrix_Declarations |sort
>> ./bindings/ada/plplot_auxiliary.ads.cmake
>> ./cmake/modules/ada.cmake
>>
>> I would advise editing all the above *.cmake files to get rid of the
>> references to the variables Ada_Is_2007_With_and_Use_Numerics
>> Ada_Is_Not_2007_Vector_Matrix_Declarations. Once that change is
>> completed and you have tested it works then you should commit those
>> changes.
>>
>> After that commit I can take over and do the necessary further
>> changes
>> to make those files non-configurable (from the CMake point of view),
>> rename them without the *.cmake index in such a way that we do not
>> lose svn history of those files, and commit all those further changes
>> in such a way that we don't temporarily break PLplot. (That last
>> issue
>> has recently become important since we are using bisect methods to
>> find regressions more and more, and commits that break PLplot
>> interfere with that process unless you laboriously identify all such
>> commits to the svn-bisect software.)
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>
> Alan,
>
> I have just committed the changes that you describe--all affected Ada
> files (68 out of 70) and cmake/modules/ada.cmake. I haven't tried a
> (normal) build here but I have succeeded in doing my own private build
> in my own development system (which bypasses all of the PLplot build
> stuff) so I know the Ada code is OK. I hope you can make the changes
> at your end because I suspect that otherwise the build will fail
> (unless the ada.cmake edit overrides all new evil).
>
> Jerry
>
>
I suppose I should update this slightly old thread. I have made
changes to the documentation and added suitable comments to the Ada
code but I suppose I shouldn't assume that anyone has read it yet.
The problem, in part, arose from some difficulty with at least some
Linux distros having trouble linking to BLAS and LAPACK. (There has
recently been someone else commenting on comp.lang.ada in a non-PLplot
context of similar problems.) I then decided that it probably wasn't
worth the hassle to link to those Ada 2005 specific libraries anyway
since only two type declarations were being used.
I then inserted my own versions of those declarations so that all Ada
builds now should work without complaining about blas and lapack since
they are never invoked.
However, the effect on the user program in some cases will not be as
benign as I first thought (my own included). The reason is a
peculiarity of the Ada type system. Specifically, you can declare a
type in one source file and declare the exact same type in another
source file and Ada thinks they are different types and will not allow
mixing them (without the user doing an explicit type conversion.) So
even though I have provided equivalent declarations for Vectors and
Matrices as is provided by Ada proper, they are incompatible.
User programs that previously relied on the built-in declarations of
Vector and Matrix _might_ now have a problem. Those Ada users and
future Ada users have three choices in how they use PLplot:
- Use it as-is and not rely on Ada-supplied Vector and Matrix
declarations.
- Make very minor edits to PLplot.auxiliary.ads and recompile _only_
the Ada bindings. (This is what I do.) Thus, the user can declare
Vector and Matrix entities that are types of the "official" Ada types.
- The user doesn't want to edit any PLplot code but wants to declare
his/her own Vectors and Matrices using the "official" Ada types. In
this case, do nothing to the source code but do type conversions of
the user's Vector and Matrix entities to the PLplot Vector and Matrix
types. This is sometimes an overlooked feature of Ada and probably
incurs no run-time overhead.
By the way, the GNAT GPL build recently released by Adacore for OS X
10.6, Snow Leopard, properly links to the BLAS and LAPACK frameworks
by means of linker pragmas in i-forbla.adb. Specifically, that entire
file is this:
package body Interfaces.Fortran.BLAS is
pragma Linker_Options ("-lgnala");
pragma Linker_Options ("-lm");
pragma Linker_Options ("-Wl,-framework,vecLib");
end Interfaces.Fortran.BLAS;
On OS X, the BLAS and LAPACK libraries are in the vecLib framework. I
would expect that something similar would work for Linux.
Jerry
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
