Hi Alan,
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> I just checked, and there are no validity warnings at all on my TeX platform
> (from
> Debian stable) so I am virtually positive these validity errors (all of which
> are the form
> "ID .* already
> defined") you are encountering are due to a bug in the Cygwin version of the
> validator that is used with the dblatex command.
>
Hm, perhaps we should report it on the Cygwin list.
> Note, this is just one more example of the validity checker for dblatex being
> somewhat problematic. For example, I have seen it crash with segfaults in
> the past
> whenever there was a real validity issue.
> However, it does complement the ongsmls validity checker because sometimes it
> does pick up real validity issues that the onsgmls validity checker misses.
> However,
> that latter validity checker is completely reliable in that it never produces
> a bogus
> validity error message or have any run-time problems. So be sure to install
> the
> OpenSP package on Cygwin that contains onsgmls, and always use the command
> "make validate" to validate our DocBook source code using onsgmls before
> actually
> building our documentation.
>
That should definitely be worth doing.
> > [...]
> the output is the result from the _second_ pass with make (the first fails as
> nm can
> not find
> "<build-directory>/src/libplplot.so")
>
> This build issue still continues to completely puzzle me. I don't confirm
> that issue on
> my platform, and I can see nothing wrong with the CMake code that enforces the
> constraint that the plplot library MUST be built before the nm command is
> executed.
> But obviously from your and Phil's experience there is still something
> problematic
> with the CMake dependency logic (or maybe even a Cygwin CMake bug?) which
> allows nm to be run before the library is built so you are forced to use that
> double
> build workaround to get around it. So the only advice I can give you is
> continue to
> use that workaround, but this is not very satisfying since I completely
> dislike
> "computer magic" like this.
>
What I noticed is that it is complaining about a shared object in the src
subdirectory. On Cygwin as well as MinGW/MSYS and bare Windows this file is
built in the dll subdirectory. Could that be an indication of what is going
wrong?
> Because of these nagging build dependency issues and bogus validity issues
> please
> carefully check the resulting Cygwin-generated documentation (e.g., do a
> detailed
> read of some section in plplotdoc-print.pdf that you are familiar with) to
> make sure it
> looks good, and if you do spot any issues in the Cygwin-generated version,
> you can
> compare with http://plplot.sourceforge.net/docbook-manual/plplot-5.10.0.pdf
> to see
> whether that same issue occurred for the Linux-generated version.
>
Right, will do.
Regards,
Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
