Re: configure.py: convert warnings to errors for pre-release?
On Sat, Feb 17, 2018 at 09:53:42PM +, José Abílio Matos wrote: > Where I would appreciate some help is to categorize those 7 events, as I said > above I do not > think that "Latex not usable (not LaTeX2e) " is warning, I would say that it > critical. +1 > So basically go to lib/configure.py and search for logging.warning, please > help me to categorize > those messages, raising (if necessary) the logging level. > > What do you think? Sounds good to me. I don't think we should change anything for 2.3.0. I can help classify (i.e. give opinion on which categories) after 2.3.0 is out. Thanks for proposing this. Scott signature.asc Description: PGP signature
Re: configure.py: convert warnings to errors for pre-release?
On Saturday, 17 February 2018 15.27.48 WET Scott Kostyshak wrote: > On Sat, Feb 17, 2018 at 01:53:55PM +, José Abílio Matos wrote: > > What are the cases where a bigger warning is expected? > > I don't have anything specific in mind. There are seven instances of > "logger.warning" if you want to search for specific cases. > > Scott The more I look into it the more I think that the warnings in the configure.py should be either critical or at least error. Those are the most severe logging levels (the others are warning, info, debug and notset). We can define other levels but I think that those are more than enough. Actually we had a message from Fernando Perez (from jupyter's hall of fame) ~ 10 years ago regarding the logging levels for lyx2lyx. The question then becomes about what shall we do if we encounter one of the them. So basically we can set a counter for each of those types and return an error code if the counters above a given threshold are positive. Where I would appreciate some help is to categorize those 7 events, as I said above I do not think that "Latex not usable (not LaTeX2e) " is warning, I would say that it critical. So basically go to lib/configure.py and search for logging.warning, please help me to categorize those messages, raising (if necessary) the logging level. What do you think? Best regards, -- José Abílio
Re: configure.py: convert warnings to errors for pre-release?
On Sat, Feb 17, 2018 at 01:53:55PM +, José Abílio Matos wrote: > > What are the cases where a bigger warning is expected? I don't have anything specific in mind. There are seven instances of "logger.warning" if you want to search for specific cases. Scott signature.asc Description: PGP signature
Re: configure.py: convert warnings to errors for pre-release?
On Mon, Feb 12, 2018 at 08:57:50AM +, Jean-Marc Lasgouttes wrote: > When I wrote this, I thought about a warnings dialog. But now I think that a > separate log file (configure_errors.log) might be better. It is easier to > check that the file is not empty. Ah I see what you mean. Yeah that could work. But it is just as easy to redirect STDERR manually and check that it's not empty. I'm not sure it is worth it. Tools such as valgrind have options for this I think, but I imagine that's because the log can be so large. With configure, the STDERR output would not commonly be large (I hope). Scott signature.asc Description: PGP signature
Re: configure.py: convert warnings to errors for pre-release?
On Mon, Feb 12, 2018 at 08:47:04AM +, Pavel Sanda wrote: > Scott Kostyshak wrote: > > additionally whether it would > > make sense to turn this option on by default when using > > --enable-build-type=pre (autotools) and -DLYX_RELEASE=OFF (CMake). > > I don't think this is smart, imagine you bisect and have to deal > with one layer of "errors" above it. Pavel Makes sense. Thanks for taking a look. Scott signature.asc Description: PGP signature
Re: configure.py: convert warnings to errors for pre-release?
Le 10/02/2018 à 23:48, Scott Kostyshak a écrit : On Sat, Feb 10, 2018 at 09:17:04PM +, Jean-Marc Lasgouttes wrote: However warnings could go to standard error, I did not check, but in a quick look we write errors with logger.error() and I assume that goes to standard error. and this could be made available somehow. What do you mean? When I wrote this, I thought about a warnings dialog. But now I think that a separate log file (configure_errors.log) might be better. It is easier to check that the file is not empty. JMarc
Re: configure.py: convert warnings to errors for pre-release?
Scott Kostyshak wrote: > additionally whether it would > make sense to turn this option on by default when using > --enable-build-type=pre (autotools) and -DLYX_RELEASE=OFF (CMake). I don't think this is smart, imagine you bisect and have to deal with one layer of "errors" above it. Pavel
Re: configure.py: convert warnings to errors for pre-release?
On Sat, Feb 10, 2018 at 09:17:04PM +, Jean-Marc Lasgouttes wrote: > However warnings could go to standard error, I did not check, but in a quick look we write errors with logger.error() and I assume that goes to standard error. > and this could be made > available somehow. What do you mean? Scott signature.asc Description: PGP signature
Re: configure.py: convert warnings to errors for pre-release?
Le 10/02/2018 à 19:44, Scott Kostyshak a écrit : I'm wondering if it would be useful to add an option to configure.py that would turn warnings into errors; and additionally whether it would make sense to turn this option on by default when using --enable-build-type=pre (autotools) and -DLYX_RELEASE=OFF (CMake). Thoughts? Bump. Any thoughts? I do know enough about configure.py to know what should be flagged at bad. However warnings could go to standard error, and this could be made available somehow. JMarc
Re: configure.py: convert warnings to errors for pre-release?
On Thu, Feb 01, 2018 at 07:09:47PM +, Scott Kostyshak wrote: > Thanks to Jean-Pierre's hawk eyes, we found a potential issue in > configure.py [1]. I did not see this because I don't manually check the > configure log (although this would be a good thing to do from time to > time). > > I'm wondering if it would be useful to add an option to configure.py > that would turn warnings into errors; and additionally whether it would > make sense to turn this option on by default when using > --enable-build-type=pre (autotools) and -DLYX_RELEASE=OFF (CMake). > > Thoughts? Bump. Any thoughts? Scott signature.asc Description: PGP signature
