Re: [LyX/master] Start reporting missing citations and broken references in LaTeX build.
On Sun, Sep 08, 2019 at 12:56:44PM -0400, Scott Kostyshak wrote: > 1. Would it be more efficient to use "prefixIs()" instead of > "contains()"? Are you concerned that for some older versions there is > white space at the beginning of the line? Since this is a new feature, I'm not sure what exact line of code you are refering to, but in some cases the same err message get prepended with different strings (like "Natbib Warning:") or similar. Given that I am aware of both prefixIs/contains routines I find it more likely that contains() was actually needed :) > 2. I think we can extend this to work with biblatex. For example, > currently if there is a citation of multiple keys, if one of the keys is > undefined, there is no error. There is no instance of "There were > undefined citations" in the log file. Instead, the following is in the > .log file: > >Package biblatex Warning: The following entry could not be found >(biblatex)in the database: >(biblatex)abc123 >(biblatex)Please verify the spelling and rerun >(biblatex)LaTeX afterwards. > > The attached patch fixes this partly. It gives an error, but it does not > specify the name of the missing key in the log file. If you think you > can extend the patch to also report the missing key in the log file, > please go ahead (I'm not interested in spending more time on this at the > moment). Otherwise, should I at least commit this attached patch? I can > change the prefixIs() to contains() if you prefer. I never worked with biblatex, so feel free to update the code any way you see fit. If you want me to check it I would need example file(s) how to reproduce your scenario. In any case it's unlikely I will have time for any coding in the forthcoming month... Pavel
Re: linking error due to missing boost::assertion_failed_msg()
On 08/09/2019 20:47, pdv wrote: On 08/09/2019 17:47, Kornel Benko wrote: Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere: In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and GuiClipboard.cpp) I don’t see macro’s which could optionally include the relevant code which is probably in the boost::crc module. I suppose boost::crc uses boost::array where the BOOST_ASSERT_MSG macro is activated, triggering the error. LyX includes a 3thparty boost-version (1.68), but I don’t find any references to it in my XCode project and I think I’m actually using my macports boost (which is 1.71). This might explain it: I’ve upgraded my macports boost and this breaks my lyx-build. There isn't any, if you don't use GCC. See CMakeLists.txt:162 Kornel XCode uses clang and I believe that indeed the internal (3thparty) boost is used. But this contains only the regex (and signals) source code, besides (all) the headers. The code involved #includes and I suppose this code is found in the system (macports) boost. Patrick That was stupid. Boost is mostly header-only with the regex and signals modules being exceptions. Patrick
Re: linking error due to missing boost::assertion_failed_msg()
On 09/09/2019 11:49, pdv wrote: On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote: Le 08/09/2019 à 14:14, Patrick De Visschere a écrit : LyX includes a 3thparty boost-version (1.68), but I don’t find any references to it in my XCode project and I think I’m actually using my macports boost (which is 1.71). This might explain it: I’ve upgraded my macports boost and this breaks my lyx-build. I had started to update our boost to 1.70, but I gave up because of issues related to this and having other things to do with my time. I will have to try again. Patrick, you should be able to force LyX to use the included boost versions. JMarc No problem. So far I have not found out how I can use macports aspell, magic , ... and not boost. But all I have to do to get macports boost1.71 working is to define the missing assertion_failed_msg(). So, it's not really a problem for me. Patrick I've realized that in cmake I must specify the header files themselves for the external libs, that is ASPELL_INCLUDE_DIR=/opt/local/include/aspell.h etc and not just specify the include directory ASPELL_INCLUDE_DIR=/opt/local/include The cmake variable name ASPELL_INCLUDE_DIR is somewhat misleading. ASPELL_HEADER (like ICONV_HEADER) would be more appropriate. This solves it. Patrick
Re: linking error due to missing boost::assertion_failed_msg()
On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote: Le 08/09/2019 à 14:14, Patrick De Visschere a écrit : LyX includes a 3thparty boost-version (1.68), but I don’t find any references to it in my XCode project and I think I’m actually using my macports boost (which is 1.71). This might explain it: I’ve upgraded my macports boost and this breaks my lyx-build. I had started to update our boost to 1.70, but I gave up because of issues related to this and having other things to do with my time. I will have to try again. Patrick, you should be able to force LyX to use the included boost versions. JMarc No problem. So far I have not found out how I can use macports aspell, magic , ... and not boost. But all I have to do to get macports boost1.71 working is to define the missing assertion_failed_msg(). So, it's not really a problem for me. Patrick
Re: linking error due to missing boost::assertion_failed_msg()
> On 9 Sep 2019, at 00:41, Stephan Witt wrote:
>
> Am 08.09.2019 um 22:44 schrieb Patrick De Visschere :
>>
>>
>>
>>> On 8 Sep 2019, at 21:03, Stephan Witt wrote:
>>>
>>> Am 08.09.2019 um 20:47 schrieb pdv :
On 08/09/2019 17:47, Kornel Benko wrote:
> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
>> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp
>> and GuiClipboard.cpp) I don’t see macro’s which could optionally include
>> the relevant code which is probably in the boost::crc module. I suppose
>> boost::crc uses boost::array where the BOOST_ASSERT_MSG macro is
>> activated, triggering the error.
>>
>> LyX includes a 3thparty boost-version (1.68), but I don’t find any
>> references to it in my XCode project and I think I’m actually using my
>> macports boost (which is 1.71).
>> This might explain it: I’ve upgraded my macports boost and this breaks
>> my lyx-build.
>>
>>
> There isn't any, if you don't use GCC. See CMakeLists.txt:162
> Kornel
XCode uses clang and I believe that indeed the internal (3thparty) boost
is used. But this contains only the regex (and signals) source code,
besides (all) the headers. The code involved #includes and
I suppose this code is found in the system (macports) boost.
>>>
>>> I have it in lyx/3rdparty/boost/boost/crc.hpp …
>>>
>>> Stephan
>>
>> Me too. But XCode picks up the one in macports.
>>
>> And there is no source code (crc.cpp) or no lib to link with.
>
> I’m using a build script for cmake Xcode project generation. It contains:
>
> XCODE_SDK_PATH=${SDKROOT:-$(xcrun --show-sdk-path)}
> echo Using SDK ${XCODE_SDK_PATH}
> cmake … \
> -DCMAKE_SYSTEM_PREFIX_PATH="/usr;${XCODE_SDK_PATH}/usr“
> …
>
> Does it do the trick for you?
>
> Stephan
No :(
I’ve noticed that the XCode compile command contains the "-I/opt/local/include"
directive; because the “Header Search Paths” is set that way in the project;
This is inserted by cmake because I use macports aspell and magic.
Patrick
smime.p7s
Description: S/MIME cryptographic signature
