This one is ugly, the Yacc generated header is used in lots of places;
the dependencies are already right because using the header requires
using the dbtools library which builds the YaccTarget, so just yet
another include path has to be added.
Change-Id: I031fde80ac326551d4719533305b1ae35351ca43
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
Also switch BOOLEAN constructor from sal_Bool to bool.
old/new signed/unsigned storage situation:
-------------------------------------------------------
SQL type | signed | unsigned old | unsigned new
-------------------------------------------------------
TINYINT | sal_Int8 | sal_Int16 | sal_uInt8
SMALLINT | sal_Int16 | sal_Int32 | sal_uInt16
INTEGER | sal_Int32 | sal_Int64 | sal_uInt32
BIGINT | sal_Int64 | pValue (String*) | sal_uInt64
-------------------------------------------------------
When sticking an UNSIGNED TINYINT into an Any,
silently promote it to UNSIGNED SMALLINT (that is sal_uInt16),
else Any would take it as a sal_Bool and normalise to
sal_True (1) or sal_False (0).
When constructing an ORowSetValue from a sal_Bool,
silently keep it as an unsigned 8 bit integer
(that is understand it as a sal_uInt8).
This will work in most cases,
since when asked back for a bool or sal_Bool,
we'll give back the right value.
Only code looking at the type tag could possibly
make a "wrong" decision.
The main (hopefully only?) path
through which this would happen is
through an implementation of
XParameters::setBoolean
XRowUpdate::updateBoolean
that would use its sal_Bool argument
to construct an ORowSetValue.
So make sure each implementation
constructs a proper BOOLEAN so as not to get confused.
For authorship/copyright purposes, this patch is a cooperation between
Lionel Elie Mamane <lionel@mamane.lu>
and
David Ostrovsky <david@ostrovsky.org>
Change-Id: I3f1f08716127147f077bff4edb6ec558b1b09e09
GUI only takes values UNX or WNT, so it is fairly pointless. One can check
whether OS is WNT or not instead.
Change-Id: I78ae32c03536a496a563e5deeb0fca78aebf9c34
Reviewed-on: https://gerrit.libreoffice.org/1304
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
The problem is that ado driver creates a link file in the tree
leaving it dirty: tinderbox doesn't like it. Instead of reading
the mdb file direct from srcdir we copy it first to workdir and
read it from there with the new function: getPathFromWorkdir.
Thank you Norbert!
Change-Id: I504bc26b80686db55a505bac19a95cc9c6022fcc
Reviewed-on: https://gerrit.libreoffice.org/1004
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
...if not even mozab. Otherwise, there is no implementation of
com.sun.star.mozilla.MozillaBootstrap and "File - Digital Signatures... - Sign
Document..." cannot show any certificates from Mozilla profiles.
Change-Id: Ie9b73fad798b2c2a3b52ba374ea967401694f685
Sure, little point for them with the other stuff here in connectivity
either, but those parts at least compile. If/when I get back to
getting the --disable-database-connectivity thing to work, all of
conectivity will be bypassed for Android and iOS, of course.
Change-Id: I4eeeb9ccdf46fb2e1df8bf75aef63e17cbb97bbf
And reverted for now the configure error when --enable-mozilla on non-Windows;
it is still used for other features, too.
Change-Id: I1ce5ff1a7a3d140a1ab7ba1e905166d91229c926
On all non windows platforms no mozilla is used any more.
On windows it used for O and OE address book access.
Once alternative implementation for it exists,
mozilla can be stripped there too.
Change-Id: I54144005e6a284326b45a34eb958d170e872471e
Reviewed-on: https://gerrit.libreoffice.org/637
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
This is a preparation for merge into master, feature/mork
branch is obsoslete and shouldn't be used any more. In
context of this change the usage of old mozilla based mork
driver depends on platform: all non windows platforms use
this new mork driver, windows still uses mozilla.
Because mozilla driver shipping was stripped on feature/mork
branch for all platforms, the corresponding commits were
changed prior to creating this change (the build file changes
are reverted now). So the build and shipping of different mork
driver implementation should be implemented from scratch:
mozilla on windows, new mork dirver on all other platforms.
Currently the new mork dirver is compiled (on all platforms),
but not used. It can be tested with mork_helper executable.
fdo#51004
Change-Id: Ib2413ab6856f163337aa311c4bf7b1182d6c6f63
Reviewed-on: https://gerrit.libreoffice.org/635
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
