------------------------------------------------------------------------ r220 | airwin | 2019-01-30 23:10:35 -0800 (Wed, 30 Jan 2019) | 10 lines Changed paths: M /trunk/README.Release_Manager_Cookbook Update to the lastest version of the instructions for the release manager This file should reflect the actual commands and actual results of those commands for this release. And it is up to date in that regard for what has gone on so far in this release. However, in case there are a few further tweaks necessary in the description of the commands in the rest of the release process, then this file should be updated again to reflect those changes just after the release. ------------------------------------------------------------------------ r219 | airwin | 2019-01-30 12:38:40 -0800 (Wed, 30 Jan 2019) | 8 lines Changed paths: M /trunk/README.cumulated_release M /trunk/README.release Finalize release notes for the forthcoming release of libLASi-1.1.3 As part of this change, I have prepended README.release into README.cumulated_release so if there are any added tweaks after this before the libLASi-1.1.3 release both README.release and README.cumulated_release should be tweaked in the same way. ------------------------------------------------------------------------ r218 | airwin | 2019-01-29 22:26:05 -0800 (Tue, 29 Jan 2019) | 10 lines Changed paths: D /trunk/CONCATENATED_README.release A /trunk/README.cumulated_release (from /trunk/CONCATENATED_README.release:217) Rename CONCATENATED_README.release => README.cumulated_release This new name for this cumulation of release notes follows how this file is named in PLplot. Note, before making this name change I double-checked that this file contained all recent release notes up to and including the last (1.1.2) release. ------------------------------------------------------------------------ r217 | airwin | 2019-01-29 19:30:55 -0800 (Tue, 29 Jan 2019) | 18 lines Changed paths: M /trunk/README M /trunk/cmake/modules/lasi_version.cmake Bump package version from 1.1.2 to 1.1.3 and library SOVERSION from 1 to 2 in anticipation of the 1.1.3 release The bump in just the patch number of the package version reflects that only maintenance and no new development has occurred for this release. However, that maintenance did involve necessary but relatively minor backwards-incompatible changes to the libLASi API (a change in the PostscriptDocument::GlyphId::GlyphId protected method API that is designed for internal use only and the addition of the PostscriptDocument::PangoItem_do protected method that is also designed for internal use only). As a result of these backwards incompatibilities, the library SOVERSION had to be bumped from 1 to 2 to force users of this library (e.g., the PLplot psttf device driver) to do the required recompilations for this case. However, there is no need for users to actually change their source code to adjust to these backwards incompatibilities. ------------------------------------------------------------------------ r216 | airwin | 2019-01-29 18:38:11 -0800 (Tue, 29 Jan 2019) | 36 lines Changed paths: M /trunk/examples/CMakeLists.txt A /trunk/examples/ComplexTextLayoutExample.png D /trunk/examples/Example_1_Result.png D /trunk/examples/Example_2_Result.png M /trunk/examples/Makefile.examples.in A /trunk/examples/MissingGlyphExample.png A /trunk/examples/SimpleLASiExample.png Reorganize how examples are built and run and replace old PNG snapshots with new ones All references to a numerical "example[0-2]" core name style for example applications and results have now been replaced by the more descriptive core names MissingGlyphExample, SimpleLASiExample, and ComplexTextLayoutExample. This core name change also makes the names of example applications and results consistent with the name of the source code used for each of the examples. These examples now do the appropriate bounding-box calculations so the results for all three of these examples are now in valid EPS (Encapsulated PostScript) format. Accordingly the suffix of the results of these applications has been changed from ".ps" to ".eps". (This change in suffix is necessary before inkscape will honor the bounding boxes.) The new PNG snapshots generated by inkscape (now automatically calculated in the build tree as a result of building the "all" target) are much higher quality than the previous decade-old snapshots because (i) pango is much more advanced than it was a decade ago, (ii) Linux fonts are much better than they were a decade ago, and (iii) inkscape does a better job of converting to PNG format than whatever (likely commercial) application was used for such conversion a decade ago. Accordingly I have removed the old PNG results from the examples subdirectory of the source tree and replaced them with the current build-tree results (on the Debian Testing platform) for MissingGlyphExample.png, SimpleLASiExample.png, and ComplexTextLayoutExample.png Tested by: Alan W. Irwin on Linux (Debian Testing) by following all the shared library and static library build-tree and installed examples tree test steps documented in a local variation of README.Release_Manager_Cookbook that will soon be committed. All these tests passed without any issues. ------------------------------------------------------------------------ r215 | airwin | 2019-01-29 18:11:58 -0800 (Tue, 29 Jan 2019) | 4 lines Changed paths: M /trunk/CMakeLists.txt M /trunk/src/CMakeLists.txt Insert copyright notice in CMakeLists.txt and src/CMakeLists.txt In addition I fixed a CMake version number typo in the CMakeLists.txt comments. ------------------------------------------------------------------------ r214 | airwin | 2019-01-29 18:08:50 -0800 (Tue, 29 Jan 2019) | 2 lines Changed paths: M /trunk/examples/README Substantial update of the documentation of the examples ------------------------------------------------------------------------ r213 | airwin | 2019-01-25 12:57:27 -0800 (Fri, 25 Jan 2019) | 85 lines Changed paths: M /trunk/include/LASi.h M /trunk/src/psDoc.cpp Make glyph names have a one-to-one relationship with glyphs This change to the glyph name (for the uncommon but not rare case when FT_HAS_GLYPH_NAMES(face) is false for a given font) changes the glyph name calculated by the nameof static function from LASi_glyph_ where unique number was incremented every time nameof was called to LASi_glyphU+. with a fallback to the unique number name approach if the UCS4 hexadecimal code for the glyph could not be determined for some reason. This change to the UCS4 version means there is now a one-to-one relationship between unique glyph name and glyph. This has several advantages: * The unique glyph name is always the same for the same glyph regardless of the order in which glyphs are encountered in strings. This improvement eliminated the PLplot differences due to different glyph names between octave results (calculated for all our standard Octave examples with just one octave session) and C results (calculated with a separate application for each of our standard C examples). * When bounding-boxes are calculated using the get_dimensions method and text renderered with the show command, nameof is called twice with the same glyph. For that case, the unique number approach calculated two different glyph names for the same glyph resulting in redundant glyph functions (with different unique number names but same contents) being stored in the PostScript header. That libLASi misfeature has been eliminated with the new UCS4 glyph naming approach. * The new version of the glyph names contains the UCS4 information for the glyph which allows users to understand (with the aid of applications such as gucharmap) exactly which glyph their application was asking to be rendered. This additional glyph information is quite useful when debugging results. The implementation of this change required copying (with a small adaptation) the C-style static function utf8_to_ucs4 from PLplot as allowed by the LGPL license for PLplot. This change also required the following backwards incompatibility to the libLASi API - GlyphId(FT_Face, const FT_UInt); + GlyphId(FT_Face, const FT_UInt, uint32_t unichar); Since this is a protected method that is normally only used internally it is anticipated that few if any libLASi users will have to actually change their code due to this change. (For example, this is the case for PLplot which depends completely on libLASi for its psttf device driver implementation.) However, all libLASi users will have to recompile their code due to this change so to force that I plan to bump the SONAME for the libLASi library (as usual for any backwards-incompatible change) before the forthcoming release of the libLASi software. Tested by: Alan W. Irwin on Linux (Debian Testing) by configuring libLASi, building it with "make", and testing it with "ctest --verbose". The results for all three examples continued to look good. And the redundant glyph functions in the PostScript headers are now eliminated with the UCS4 codes double-checked with gucharmap for example 2 in a couple of cases. Further PLplot test: I installed this updated liblasi library and configured a PLplot build to use that installed version for its psttf device driver and also specified -DPLPLOT_TEST_DEVICE=psttfc to use that device for the test_diff_device target. I built that target (which compares psttfc results for all examples written in all our supported languages). The test_diff_device report was perfect, i.e., the octave differences that occurred before because of different glyph function names in the header are now gone. In addition, the triple redundancy (presumably because that device calls bounding box twice) in glyph functions is now also gone. In sum, this change has nicely eliminated a number of minor (because FT_HAS_GLYPH_NAMES(face) is false only for relatively few fonts) libLASi issues. ------------------------------------------------------------------------ r212 | airwin | 2019-01-24 02:32:58 -0800 (Thu, 24 Jan 2019) | 121 lines Changed paths: M /trunk/examples/MissingGlyphExample.cpp M /trunk/include/LASi.h M /trunk/src/psDoc.cpp Work around libLASi issue that occurs when pango chooses pure bitmapped fonts An example of such a pure bitmapped font is the popular Noto Color Emoji. For glyphs such as "Unicode U+2648 ARIES: ♈", pango (presumably due to the default configuration of fontconfig on my Debian Testing system) chooses this font to render this glyph (and some other fairly common glyphs as well). Of course, this font is incompatible with libLASi since that library can only use scalable outline fonts rather than bitmapped ones. The (DEBUG) result for this incompatible pango choice was FT_Load_Glyph is returning error = 24 for a glyph index of 52 associated with the substring ♈♈ where 24 (see ) corresponds to "Invalid_Size_Handle" which I assume means simply that pure bitmapped fonts cannot be scaled (one of the font attributes that libLASi obviously needs). Prior to this commit, the libLASi response for any FT_Load_Glyph error was to try again with a glyph index of 0 (normally used to obtain the default replacement glyph for the type face). But, of course, the exact same error as above is obtained for this glyph index as well for Noto Color Emoji. Therefore, the result of this glyph index 0 error condition was libLASi aborted which is not an acceptable result due simply to the overall popularity of Noto Color Emoji. Of course, this library abort can be avoided if fontconfig is reconfigured to avoid bitmapped fonts or (almost equivalently) the user uninstalls the Noto Color Emoji font package, but such "solutions" are not acceptable in general because of the popularity of this font for many other tasks where a bitmapped font is fine. Ideally, the solution to this issue would be to ask pango to only choose outline fonts, but I am not aware of any method of making such a request of that library. So unless or until such a method is discovered (or developed) for the pango library, the only solution to this issue is to find a libLASi workaround when the above glyph index 0 response to a FT_Load_Glyph error also errors out. This commit implements such a workaround which is to substitute the default replacement glyph for each glyph in the PangoItem (corresponding to a run of characters that can all be rendered with a font of fixed family, slant, weight, and width (but not size)). whenever such an error is discovered for any glyph in a PangoItem. The chosen emergency glyph is "\n" which experience shows reliably forces the glyph index 0 code path which replaces that linefeed with the default replacement glyph (normally an empty box). So the net result is the default replacement glyph is rendered now for all error cases. I have updated the explanatory text in MissingGlyphExample.cpp to be consistent with this conclusion. N.B. as part of this fix I transferred the PangoItem processing part of the code in the for_each_glyph_do method (which is a misnomer since it should really be called for_each_string_do) to a new PostscriptDocument method called PangoItem_do. This code reorganization makes the code substantially easier to understand with PangoItem_do doing most of the work, and for_each_glyph_do responding to any errors reported by that method which it could not handle itself with the glyph_index 0 code path. Unfortunately this reorganization means the new routine PangoItem_do must be a protected class method (rather than a simple C-style static routine) because it uses protected data from the PostscriptDocument class. This change is a backward-incompatible change to libLASi.h and the libLASi library which will require users of that library to recompile their code against the changed libLASi.h. However, this backwards-incompatible change will not require them to actually change their code. Tested by: Alan W. Irwin on Linux (Debian Testing) by configuring libLASi, building it with "make", and testing it with "ctest --verbose". The results for the "Missing Glyphs" showed empty boxes (the expected default replacement glyph) for both the missing glyphs and all (two) Aries glyphs associated with a PangoItem font face where pango chose the Noto Color Emoji font. Further tests: * I ran all three examples under valgrind with no memory management issues other than memory leaks reported. * I installed this updated liblasi library and configured a PLplot build to use that installed version for its psttf device driver and also specified -DPLPLOT_TEST_DEVICE=psttfc to use that device for the test_diff_device target. I built that target (which compares psttfc results for all examples written in all our supported languages). The test_diff_device report was clean except for octave Missing examples : 24 Differing graphical output : Missing stdout : Differing stdout : which further investigation showed was simply an artifact of the octave calculation being done with one octave session so that the unique lasi_index number associated with broken fonts that fail the !FT_HAS_GLYPH_NAMES(face) test is different for octave compared to the C examples. * I viewed all 33 C standard example results built as part of the test_diff_device target build using the gv PostScript viewer. In all cases (except for example 7 where the signs of the zodiac came out as empty boxes because of the Noto Color Emoji choice by pango) the rendering of the examples looked good. In sum the only issue I could find for any of these tests is duplicated (due to bounding-box calculations) GlyphId's in those rare cases where a font failed the !FT_HAS_GLYPH_NAMES(face) test. That duplication lead to redundant glyph information (with different LASi_glyph_* titles but duplicate contents) being stored in the headers of the PostScript results. The only way to address this issue is to not call GlyphId when bounding boxes are being calculated, but I don't know how to implement such a test. Furthermore, I judge this to be a minor issue because relatively few fonts are sufficient broken to fail the !FT_HAS_GLYPH_NAMES(face) test so I am going to live with this issue. ------------------------------------------------------------------------ r211 | airwin | 2019-01-23 16:24:48 -0800 (Wed, 23 Jan 2019) | 31 lines Changed paths: M /trunk/examples/MissingGlyphExample.cpp Modify the "Missing Glyph" example again In this case I replaced - "Unicode U+1878 MONGOLIAN LETTER CHA WITH TWO DOTS: ᡸ", + "Embedded newlines a\\nb\\nc: a\nb\nc", because I have verified experimentally that inserting a newline character (and presumably any other non-printing character) in the character string generates a missing glyph condition that results in the replacement glyph (normally an empty box) being substituted by the libLASi code. So this appears to be a much more reliable way (compared to random unicode glyphs that happen not to be available now but which will likely become available later) in the long run to test the response of libLASi to missing glyphs. Tested by: Alan W. Irwin on Linux (Debian Testing) by configuring libLASi, building the all target, running ctest, and verifying with gv that the resulting Encapsulated PostScript file has substituted the missing glyph empty box for the embedded newlines. N.B. this test was done for a modified version of examples/MissingGlyphExample.cpp where the Aries symbols were dropped. Of course, with those symbols restored to the example as in this commit, ctest errors out as before because of the attempt to use an unsuitable pure bitmap font (Noto Color Emoji) to handle the Aries glyph. A solution to that remaining libLASi issue has been found but it is not commit-ready yet (and it was not used for the present test). ------------------------------------------------------------------------ r210 | airwin | 2019-01-22 17:35:57 -0800 (Tue, 22 Jan 2019) | 87 lines Changed paths: M /trunk/examples/MissingGlyphExample.cpp Update "Missing Glyphs" example to provide more stringent tests of the libLASi library One on-going testing issue with this example is Debian fonts are constantly improving. So in contrast to the Debian Jessie case, Debian Testing provides all the glyphs for the previous version of this example which therefore no longer tests libLASi's response to missing glyphs. So to address that issue (at least temporarily) I have added "Unicode U+1878 MONGOLIAN LETTER CHA WITH TWO DOTS: ᡸ" to the strings being rendered by this example. This means this example tests missing glyphs again for me since this glyph is missing for the (extensive) set of Debian Testing font packages I currently have installed. One important libLASi defining characteristic is this library can only use scalable outline fonts. Until recently this has largely been only a theoretical concern because fontconfig was typically set up to prefer modern outline fonts over old-fashioned bitmapped fonts. However, that all changed with the advent of the Noto Color Emoji family of fonts which are high-quality pure *bitmapped* fonts suitable for rendering the extraordinarily popular emojis. Currently, for Debian Testing at least, pango/fontconfig chooses this font over suitable outline alternatives (likely because of that emoji popularity), and there doesn't seem to be any way to overcome this problem other than to remove the Noto Color Emoji font package, wait for an outline version of that family of fonts to become available, or (to express a really bad alternative) to configure fontconfig in one way when using libLASi and another way when desiring emoji's for text transmissions. Also, pango/freetype does not appear to have any programming method to force outline fonts to be chosen. So going forward the plan is to change libLASi to substitute blank glyphs for all glyphs in a PangoItem where an error occurs (e.g., due to missing glyphs or a pure bitmap font being chosen by pango for the PangoItem). (Note a pango item is associated with a sub-block of text that can be rendered with a single font face, i.e., a group of fonts constrained to have the same family, weight, slant, stretch and width but possibly varying sizes). To test this situation for the current libLASi, I have inserted in this commit the test string "Unicode U+2648 ARIES (twice): ♈♈" where it turns out that pango currently selects the completely unsuitable (from the libLASi perspective) pure bitmap font "Noto Color Emoji" to represent those Aries symbols. (This issue with the Aries symbol was first discovered by PLplot comprehensive testing of the psttf device driver which depends on libLASi.) In addition, I have taken this opportunity to move from the "Arial" font to the more generic "serif" font which presumably gives fontconfig the same or even more freedom to choose the best font to render a particular glyph. And I have also changed all test strings being rendered in this example to ones that describe themselves in more detail, e.g., "Unicode U+0802: ࠂ" was replaced by "Unicode U+0802 SAMARITAN LETTER GAMAN: ࠂ" Tested by: Alan W. Irwin on Linux (Debian Testing) by configuring LASi (using the Debian Testing system version (3.13.2) of cmake), building the "all" target, and running ctest --verbose. The result for this commit of the "Missing Glyphs" example was as follows: [...] test 1 Start 1: example0 1: Test command: /home/software/lasi_svn/HEAD/build_dir/examples/example0 "example0.ps" 1: Test timeout computed to be: 9.99988e+06 1: Error returned from FT_Load_Glyph 1/3 Test #1: example0 .........................***Failed 0.08 sec [...] A test with the previous version of this example produces no such errors which confirms the new version of this example is a more stringent test of libLASi. N.B. this ctest error will continue until the libLASi library can be changed as discussed above. ------------------------------------------------------------------------ r209 | airwin | 2019-01-22 15:52:19 -0800 (Tue, 22 Jan 2019) | 27 lines Changed paths: M /trunk/src/drawGlyph.cpp M /trunk/src/psDoc.cpp Replace deprecated lower-case variants of Freetype macro constants with preferred upper-case form That is change libLASi references to ft_glyph_bbox_unscaled and ft_glyph_format_outline with FT_GLYPH_BBOX_UNSCALED and FT_GLYPH_FORMAT_OUTLINE. Tested by: Alan W. Irwin on Linux (Debian Testing) by configuring libLASi with the system version (3.13.2) of cmake and building the libLASi library (with "make LASi") without build errors. Note the above deprecation of the lower-case form of the macro constants was only noted by chance in documentation, and the actual libLASi build continues to generate deprecation warnings due to other long-standing issues. Those issues (some of which have multiple instances) are the following: * "warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]" * "warning: ‘PangoContext* pango_ft2_get_context(double, double)’ is deprecated: Use 'pango_font_map_create_context' instead [-Wdeprecated-declarations]" * "warning: ‘FT_FaceRec_* pango_ft2_font_get_face(PangoFont*)’ is deprecated: Use 'pango_fc_font_lock_face' instead [-Wdeprecated-declarations]" All of these are beyond my current C++ and pango skill level to fix so help with cleaning up these deprecation warnings would be much appreciated! ------------------------------------------------------------------------ r208 | airwin | 2019-01-22 14:34:44 -0800 (Tue, 22 Jan 2019) | 77 lines Changed paths: M /trunk/examples/ComplexTextLayoutExample.cpp M /trunk/examples/MissingGlyphExample.cpp Add boundary boxes to the "Missing Glyph" and "Complex Text Layout" examples This change was straightforward for the "Missing Glyph" case. For the "Complex Text Layout" case, I implemented some generally useful C++ code macros (called LASI_SHOW_AND_UPDATE_BB, LASI_SCALED_SHOW_AND_UPDATE_BB, and LASI_ROTATED_SHOW_AND_UPDATE_BB), which made it straightforward to handle even complex cases such as anamorphic scaling and rotation of text. For example, the LASI_ROTATED_SHOW_AND_UPDATE_BB macro includes C++ code to apply the rotation matrix to determine the x,y coordinates of the corners of the rotated text box and use those corner coordinates to help determine the overall bounding box. In addition, for the "Complex Text Layout" case I reduced the font size from 30 to 25 of the "UTHAITHANI IN THAI: อุทัยธานี" section of this example to compensate for what appears to be a systematic increase over the years (compared to previous screenshots of this example and other lines of text in this example) in the font actually determined by the Debian testing version of pango when the "Garuda" font is specifically requested for this component. A gucharmap experiment with requesting this font with the Debian Testing package fonts-tlwg-garuda-otf installed for the U+0E2D THAI CHARACTER O ANG "อุ" indicates that "Garuda" is the font actually used in this case. Which indicates this increase in size we are compensating for in this commit is not an artifact of the wrong font being chosen. Tested by: Alan W. Irwin on Linux (Debian Testing). In the "Missing Glyph" case the test was a simple one (using gv to check the boundary box of the complete eps result). But in the "Complex Text Layout" case, I locally reduced the example (using #if 0 ... #endif) to individual components and used the simple gv test to test the above macros were working correctly for each of those individual components and additional significant variations of those components. One such detailed test was for the red-rectangle component. By looking at the eps result, I confirmed the resulting high-res boundary box was identical with the path of the red rectangle implying that applications paying strict attention to that high-res BB would split the width of the line. And the low-res BB was slightly (less than one point in all cases which is small compared to the width of the line) outside the hig-res BB. So a similar conclusion can be drawn for those applications paying attention to the low-res BB. However, note there is a small but significant boundary-box issue with the gv PostScript viewing application. The position indicator for the app appears to conform to the low-res BB (i.e., it shows no position outside that BB), but the white background supplied by that app is not aligned properly with that BB. For example, the lower y value for that white background is systematically too low (by a significant number of points corresponding roughly to the width of the line) relative to the BB, and the upper x value is systematically too large by a similar amount. A further detailed test was for the case of anamorphic scaling of text for a number of different sequential text segments. In all cases (subject to the above minor issues with gv), the bounding box of the composite set of all such text segments was calculated properly. A final detailed test was for the rotated text component where I used sequential text rotated by various increments to prove each text segment was continuous with the previous one and rotated properly. Also, I confirmed for all these different rotation tests (subject to the above minor issues with gv), that in all cases (including one that had overall rotation angles in all quadrants) the bounding box of the composite set of all rotated text segments was calculated properly. Of course, after all those individual detailed component tests were completed, I changed the "Complex Text Layout" example to the present case where each component updates if necessary (i.e., if the component BB is larger in any dimension than the overall boundary box calculated for previous components) the overall bounding box. And a simple gv test shows that entire result looks good including an appropriate overall bounding box (subject to the above minor issue with gv). ------------------------------------------------------------------------ r207 | airwin | 2019-01-22 11:39:08 -0800 (Tue, 22 Jan 2019) | 9 lines Changed paths: M /trunk/src/psDoc.cpp Fix minor boundary box issue The low-resolution (integer) boundary box was being calculated by taking the floor of all high-resolution (double) boundary box limits. This commit changes that to the floor of the high-resolution lower limits and the ceil of the high-resolution upper limits so that low resolution bounding-box limits are always outside the high-resolution limits, but with the difference always less than one point. ------------------------------------------------------------------------ r206 | airwin | 2019-01-10 18:20:41 -0800 (Thu, 10 Jan 2019) | 26 lines Changed paths: M /trunk/Doxyfile.developer M /trunk/Doxyfile.user Update doxygen configuration files from doxygen version 1.8.1.2 to 1.8.13 These conversions were done using doxygen -u Doxyfile.developer doxygen -u Doxyfile.user Tested by: Alan W. Irwin on Linux (Debian Testing) by running (from an initially empty build tree and with the Debian Testing 3.13.2 version of CMake) cmake -DCMAKE_INSTALL_PREFIX=/home/software/lasi_svn/install -DBUILD_SHARED_LIBS=ON ../lasi_2019 >& cmake.out # To remove previously generated doxygen results in the source tree. make clean >& clean.out make all >& all.out with no doxygen build issues other than one @param warning that the parameter mapval does not occur in the argument list for PostscriptDocument::accrue_dimensions. Since mapval does appear in this argument list, this warning can only be explained by some doxygen C++ code-parsing failure. In addition, I skimmed the generated results at doc/developer/html and doc/user/html/ with firefox, and all seemed well. ------------------------------------------------------------------------ r205 | airwin | 2019-01-10 17:16:23 -0800 (Thu, 10 Jan 2019) | 24 lines Changed paths: M /trunk/CMakeLists.txt Bump (or shove hard in this case) the minimum version of CMake from 2.8.9 to 3.13.2 This change is motivated by the bug fixes in later CMake versions and also the much better checking of the build system that occurs for the policies automatically used for 3.13.2. That said, it is a tribute to the robustness of the current libLASi build system and the backwards compatibility of CMake that there were absolutely no build-system warnings either before or after this change. Tested by: Alan W. Irwin on Linux (Debian Testing) by running (from an initially empty build tree and with the Debian Testing 3.13.2 version of CMake) cmake -DCMAKE_INSTALL_PREFIX=/home/software/lasi_svn/install -DBUILD_SHARED_LIBS=ON ../lasi_2019 >& cmake.out make ctest with no issues other than outdated Doxygen configuration files (which will be the subject of the next commit). ------------------------------------------------------------------------ r204 | airwin | 2015-05-20 18:14:08 -0700 (Wed, 20 May 2015) | 45 lines Changed paths: M /trunk/src/CMakeLists.txt Build system: set target property POSITION_INDEPENDENT_CODE ON for the libLASi library This change allows shared libraries from foreign software (e.g., PLplot) to link to the static version of libLASi. The cost of this gain is there is a small amount of inefficiency (e.g., the more complicated addressing code that apparently occurs on Linux for all code compiled with the -fPIC flag) introduced for the static libLASi library. Tested by Alan W. Irwin on Linux using the following procedure (which is normally used for testing changes to libLASi): cd /home/software/lasi_svn/HEAD/build_dir # Remove build tree and install tree rm -rf /home/software/lasi_svn/HEAD/build_dir/* /home/software/lasi_svn/install # Configure libLASi build, test, and install # (Note change from normal procedure where we have specified building # a static version of libLASi.) cmake -DCMAKE_INSTALL_PREFIX=/home/software/lasi_svn/install \ -DBUILD_SHARED_LIBS=OFF ../lasi_allura >& cmake.out # Check results less cmake.out # Build and install make -j4 install >& install.out # Check results less install.out # Test ctest I then followed up with a comprehensive test of PLplot where this static libLasi library was fine for the shared library case for that build (both with and without dynamic devices). However, under these conditions the traditional PLplot static build had some (missing stdlib++) difficulties with the mixed Fortran, C++, and C case. This is expected and unfortunately there is no easy cure. Therefore some static/traditional testing limits are in train to avoid this case for future testing. ------------------------------------------------------------------------ r203 | airwin | 2014-07-26 15:31:57 -0700 (Sat, 26 Jul 2014) | 2 lines Changed paths: M /trunk/CONCATENATED_README.release Prepend the release notes for 1.1.2. ------------------------------------------------------------------------ r202 | airwin | 2014-07-26 15:31:31 -0700 (Sat, 26 Jul 2014) | 2 lines Changed paths: M /trunk/README.Release_Manager_Cookbook Update instructions to exactly what occurred for the 1.1.2 release. ------------------------------------------------------------------------ r200 | airwin | 2014-07-26 13:54:34 -0700 (Sat, 26 Jul 2014) | 2 lines Changed paths: M /trunk/ChangeLog.release Update commit messages for 1.1.2 release cycle. ------------------------------------------------------------------------