New Release 2.2.0 release ?

[hzeller]

Given that the last commit hinted that 2.2.0 is around the corner, but has been sitting there for a few months, I would like to request to create a new release.

Reason is that I'd like to use the avrxmega3 (attiny1604, attiny804,...) class of devices that have been added after the last release.

If this gets a proper 2.2.0 label and release, it is much easier to convince distributions to pick up and package this version.

Thank you!

(Currently some distributions are stuck in even older versions, but that is a different story)

[dl8dtl]

Basically, not a bad idea, but I'd need some time to at least walk through some of the bugs, and fix the most serious ones.

Going through the pull requests is probably the simpler part here.

[leonty]

Please, include in 2.2.0 the patch mentioned in https://github.com/avrdudes/avr-libc/issues/563 (pgmspace utils generic usage for tiny core MCUs). Moreover this patch has already been incorporated by Microchip in their version of avr-libc https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html?GUID-B4AD7063-9288-4E83-A857-F4FBD028A8BB

[hzeller]

@dl8dtl it seems like you're pretty busy, are there things we can help to get a release out the door ?

[kamocat]

Is there a list of issues which need to be closed before the 2.2 release? I am happy to help.

[leventelist]

I'd be happy to test an RC version of 2.2.0... if that helps.

[leventelist]

I created a fork, and applied some of the PRs above. https://github.com/leventelist/avr-libc

[anatol]

Hi, the Arch package maintainer here. Some of our users keep asking us to bring the latest avr-libc changes and make a new Arch package. But our policy is to stick to the official releases only. Thus we rely on you to provide a new 2.2.0 release.

Any ETA for 2.2.0 release date?

[dl8dtl]

The question would go to Johann, how comfortable he'd feel to roll out the status quo as v2.2.0.

Actually preparing the release is not that much work, I'll be able to find the time for that.

[dl8dtl]

Here is the result of a make distcheck from last night. If you have troubles unpacking the file, it is actually a .tar.bz2 file, but Github doesn't allow me to upload it with that extension. avr-libc-220git.zip

[sprintersb]

There's 2 problems:

1. How to deal with problems in I/O headers? Supporting it all by hand and reviewing changes introduced by device-packs is beyond any reasonable effort. Just using headers from the newest device packs makes it easier to transition from IDEs that use such packs, but it might render quite some users code invalid, so that they would have to port their code to the layout of device packs.
2. While generating HTML docs works as expected, I have considerable problem in generating PDF. 100.000+ errors due to non-existent fonts glyphs. I tried to follow the docs to install new fonts in TexLive, but that's very complicated and requires closed source stuff which is not hosted by TexLive. Plus, Doxygen generates tex files that will hang the TeX processor. It will bail out after 100 errors, but no pdf is generated. What am doing is just make pdf in $build/doc/api.

[dl8dtl]

I'd prefer keeping traditional IO headers where they exist. Atmel eventually switched to generated headers, which might (as you noticed) incompatible with ours. In particular, in the past, names in datasheets have sometimes been changed, and then, we kept the historic names for compatibility as aliases. Automatically generated headers probably would not work that way.

Also, in particular for the ATmega*RF devices, we once tried to establish a new, more error-preventing naming scheme using bitfields (similar to what can be found now with many ARMs). Atmel's auto-generated headers don't follow that scheme, but there might be sourcecode in the wild using it.

For new devices that don't have any precedence in avr-libc, we could simply use their auto-generated headers.

I'm running into troubles with compiling the documentation now myself. It seems recent doxygen produces LaTeX macro calls that just don't work (and then produce hundreds of errors). I'll investigate a bit further.

[sprintersb]

There are also the following issues with the documentation:

• release_method.html is outdated and needs a refresher, it still explains SVN stuff.
• In avr/interrupts.html#avr_signames there is a list of all ISR names for all devices, which is pretty much outdated. I'd rather add a FAQ entry on how to find IRQ names for a device than supporting more than 10000 entries...

[dl8dtl]

Updating the release stuff is probably not going to be a big deal, but first, I need a working Doxygen setup again that produces valid LaTeX.

The interrupt name table has once been automatically generated, but the infrastructure for that is now defunct (and IIRC their XML files also changed format). So yes, it needs to be written in a generic form.

[sprintersb]

Doxygen setup again that produces valid LaTeX.

The avr libc documentation says to install MiKTeX, so is TexLive supposed to work at all?

[dl8dtl]

MikTeX used to be a fairly complete TeX setup once, probably at a time when there wasn't a TeXLive at all.

Anyway, I've always been compiling it with TeXLive (as long as there used to be a TeXLive). My current issue really seems to be related to the longtabu environment which Doxygen offers as their own LaTeX implementation for tables that are defined in plain HTML in the Doxygen source. Maybe it's related to some special stuff there, we are using rowspan/colspan, for example.

All I can say: that used to compile before, with older versions of Doxygen. I just fails now.

[sprintersb]

we are using rowspan/colspan, for example

Doxygen allows rowspan/colspan and has it in its documentatio: https://www.doxygen.nl/manual/tables.html

To all of my knowledge, the only HTML-like elements are ones explicitly allowed and understood by Doxygen.

[dl8dtl]

Yes, all there. It produces LaTeX source code that contains the row and column spans, yet the LaTeX fails to compile.

[sprintersb]

I went ahead and added a new script for and version of vectortable.dox in https://github.com/avrdudes/avr-libc/commit/5021ae0eb77626a4969c253c10f53da52e522177.

• The script extracts the information from #include <avr/io.h> (hence needs some up-to-date compiler).
• The table is huge, with ~650 rows and ~12000 mcu mentions. Therefore, it's wrapped in \htmlonly.

[dl8dtl]

but first, I need a working Doxygen setup again that produces valid LaTeX.

Update on this: checking out release 2.1.0, I can compile the documentation. So, the breakage must have been introduced by one of the documentation changes since … guess I have to bisect that now, unless I can find it by reviewing the diffs.

[sprintersb]

I can compile v2.1, too (TexLive 2022), but the pdf has only images and table borders, not a single letter is visible. After

apt install doxygen-latex
apt install texlive-fonts-recommended
tlmgr install psnfss
tlmgr install helvetic

I still get zillions of Missing character: There is no ... in font nullfont! due to

kpathsea: Running mktextfm pcrro8t
.../mktexnam: Could not map source abbreviation  for pcrro8t.
.../mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; ; nonstopmode; input pcrro8t
This is METAFONT, Version 2.71828182 (TeX Live 2022) (preloaded base=mf)
kpathsea: Running mktexmf pcrro8t
! I can't find file `pcrro8t'.
...
! Font T1/pcr/m/it/10=pcrro8t at 10.0pt not loadable: Metric (TFM) file not found.
kpathsea: Running mktextfm nullfont

The infinite loop is in the longtabu environment in mem_sections.tex for table Memory Regions of the Default Linker Script. Features not used before are: <caption>, <th>, superscript.

The errors can be seen without \batchmode.

The source uses <td> without </td> which should be fine; Doxygen adds the </td>'s in the HTML version.

[dl8dtl]

not a single letter is visible

That seems like a font installation issue. I didn't run into that, I always got a readable PDF.

I could get the mem_sections.tex to compile after removing the colspan from a normal table row – maybe it's supported only in table headings? Anyway, it then stumbles across more serious errors in assembler.tex which I still did not understand nor was able to remedy them.

The source uses <td> without </td> which should be fine

It is; adding </td> doesn't change the error behaviour at all.

So it must be something else in those tables, still investigating.

[dl8dtl]

Guess we are stumbling across genuine Doxygen bugs here. :-( The first culprit I found is \anchor inside a table. If I remove all of them in assembler.dox, it compiles. (The \anchor inside a normal list can remain.) Next, it complains about LaTeX errors in the demo project now.

[dl8dtl]

I see there is a doxygen 1.11.0 just released. I have to compile it here outside of the normal FreeBSD ports infrastructure though, as they have not yet been updated.

[dl8dtl]

Unfortunately, still the same errors. :-( So guess we have to prepare a bug report, but that needs to isolate the bugs in a minimum example.

[dl8dtl]

There appears to be more breakage even in older releases. For example, most of the content for <avr/power.h> disappeared between these two releases in the LaTeX / PDF version. All that appears to be a big mess. :((

[sprintersb]

Maybe I missed some fixes like https://github.com/avrdudes/avr-libc/commit/258b20e192d320a07f3111e6a69a1218109aa5b5

[dl8dtl]

<power.h> looks OK to me, so maybe it's in another file. The various LaTeX source files are all concatenated together, so errors from other files might affect one that is later in the chain. Strange that compilation of the docs on 2.0 works even without this kind of changes – I explicitly checked it. I can still build a 2.0 documentation that is more complete.

All in all, Doxygen appears to be a very sensitive baby …

[dl8dtl]

Small update: \anchor inside a table seems to be severely broken, but it's easy enough to move the anchor just before the table. Then, it compiles now. Updated a number of things, it's right now in the documentation_fixes branch, I'm going to file a PR for that soon. Once that is done, I think we are fine for a release.

[sprintersb]

@anatol @hzeller The main obstacle for a new release (generating PDF documentation) is now out of the way. What avr-gcc version are you planning to use with the next libc release?

[anatol]

Arch Linux does not dictate a version you need to release. Arch Linux helps to bring software you provide to users. Arch always packs the latest release made by upstream (you).