Minor change to the perl postprocessing script and resulting changes to
the affected source files.
This deals with two issues:
- "foreach"-like structures were not always treated correctly
- some longer calculations that ended on "+ constant" were reformatted in
a rather unatractive manner
In one source file (divelist.c) I ended up adding braces to the sources...
trying to cascade the indentation further down without having the block
there seemed a lot more trouble than it's worth.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The struct / class regex was way too relaxed.
Having the parent class on the same line usually looks better.
clang-format appears to do something odd with continuation strings - even
with UseTab: Always it indents those with four spaces.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This hasn't been tested enought, but it seems to get really close.
It assumes that clang-format is in your patch.
Run
perl scripys/whitespace.pl FILENAME
and you'll get a diff of what it things is wrong with that file.
If you like what you see, simply pipe the output into patch -p0
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a silly perl script to create either a txt or html file from the
structured descriptor3.tsv file. This way we can maintain the structured
file and easily create both text and html output from it.
Instead of somehow adding this to qmake I decided to simply add the two
output files so that they are included in the source tar file.
Recreate them by running
perl scripts/parse-descriptor.pl descriptor3.tsv SupportedDivecomputers.html
perl scripts/parse-descriptor.pl descriptor3.tsv SupportedDivecomputers.txt
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
First, make sure we actually match /c/windows from the beginning, not
if it occurs in the middle of the path.
Second, make sure that directories containing the binaries are
searched first. Do that by using unshift (prepend) instead of push
(append).
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The correct order on Windows is:
1. Local directory (relative to the binary)
2. $PATH
3. System dirs
We insert our -L flags between 1 and 2 above.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The environment variable is to be used if the caller knows that the
default objdump can't parse Windows DLL files (COFF-PE). On Fedora,
Debian, and OpenSUSE, the default objdump can, and obviously the
native one on Windows can too.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Unix developers, look away... this is how it's done on Windows: the
binary loader searches $PATH for the DLLs, so let's reuse the same
variable. This simplifies the command-line a little.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Still, some false positives show up ('Veo 3.0' is one of them).
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The quotes are not needed either (nothing to expand there).
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Someone who is better at shell script writing needs to review this.
Here's what it's supposed to do. Create version strings with three or four
values for darwin or win, respectively, that we can use as the versions of
the bundle or installer. The version that Subsurface reports isn't
affected by this. So in a way this is automating something that's mostly
cosmetic.
If we have a 2 digit version number (like 3.0), do the same the old script
did - add just zeroes if we are on a tag, otherwise add the number of
commits since the tag (and a last 0 if on win).
If we have a 3 digit version numner (like 3.0.1), leave it alone on mac
and add either the number of commits since the tag or a zero if we are on
the tag on win.
Now this can create the same version number for two different versions on
darwin: the first commit after 3.0 and the version tagged as 3.0.1 will
both get the same number. That's kinda silly but remember - the non-tagged
versions aren't supposed to be widely distributed (and the third digit in
them should be much larger than anything we'd ever release; we are
already on commit 16 since the last tag and hopefully will never release a
3.0.16 as tagged release). And of course the full version as displayed in
the About box is always able to tell things apart because of the SHA added
at the end if it's a non-tagged version.
So why all this magic? The reason we do this is so that during development
we are able to create Mac and Windows installers and they get reasonable
version numbers, based on the versioning that these vendors suppose. And
without manual intervention.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Removed oddly named and ridiculously outdated documentation text (scripts).
Created new directory 'scripts'.
Added unified version extraction script (scripts/get-version). Yes, it's
more shell script code but faster and more maintainable than the sed commands
and the swearwords/regexps repeated over and over again.
Makefile and packaging/macosx/make-package.sh modified accordingly.
I don't do windos neither macos but, AFAICS my tests show, it should be safe.
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
(and add a reminder of how they came to be)
Gaah. XML is *stupid*. It's not easy to parse for humans or for
computers, and some of these XML files are just disgusting. But maybe
they can be turned into something usable with libxml.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
