Jannick

Wait - the issue disappeared just suddenly (CB nightly with svn version mentioned above was opened the second time, definitely not the first time). Is it possible that it occurred with a nightly build opened for the first time, but any changes to default.conf required by the new CB nightly version became effective after closing the very first session? I happened to see that the svn version is coded into default.conf. I believe this ticket can be closed then.

The Number of processes for parallel builds of the compiler was already set to 0. Did something happen to directcommands.cpp recently? Into this file I was looking a very very long time ago trying to solve bugs at the time related to processing auto-generated files. BTW: In my CB setup multiple compilers are configured for the same rule for auto-generated files (in the example above %.l -> %.scanner.c). Not sure if that helps or not.

[svn-r13518/Windows10] auto-generated c-file gets compiled twice

Confirming the behaviour for te browsers Firefox (Windows notebook) and Safari (iPad). This unfortunately makes the forum quite useless in two ways for me: threads cannot be displayed and postings cannot be submitted. ... Even reporting this error to the forum administrator is impossible after the deadlock. Removing the forum cookies is not a remedy. It appears that for logins the login period selected has an impact on whether the login works or not. It it does deadlock afterwards nevertheless. It...

link error: undefined references to get_fmode, set_fmode

First of all, sorry for the late reply. Yes - the tag gawk-xml-1.1.1 is exactly what I meant. Thanks! git provides ample features to create these tags within a couple of lines, so not a real burden as far as I can tell. Instead of putting the version number into the snapshot name (which would be redundant information and might interfer with identifying the latest snapshot file once the version number changes), the dirty git version could be put into an additional package file called, e.g., VERSION...

Hi Andy, thanks for your swift reply. Here a couple of questions important for proper versioning, in particular, which I think reveal the issues easily: In which git commit was version x.y.z of extension E released? How do you derive the git commit a snapshot of extension E published on SF is based on? How do you know that the content of a snapshot file of extension E is different from the previous downloaded one due to a relevant git commit? What is the best way to form a (dirty) version string...

versioning per extension package (release and snapshot)