Hello, All.
Currently distributed packages include GPRE but not examples for it. Shouldn't it be
either both or none?
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On Thu, 9 Jan 2020 13:14:22 +0100
Dimitry Sibiryakov wrote:
>Hello, All.
>
>Currently distributed packages include GPRE but not examples for it.
> Shouldn't it be either both or none?
>
To be more precise, the static examples are included the dynamic ones are not.
So the question sho
Better IMO: remove GPRE (and QLI) from the kits.
Adriano
On 09/01/2020 09:53, Paul Reeves wrote:
> On Thu, 9 Jan 2020 13:14:22 +0100
> Dimitry Sibiryakov wrote:
>
>>Hello, All.
>>
>>Currently distributed packages include GPRE but not examples for it.
>> Shouldn't it be either both or n
On 2020-01-09 16:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
As far as I know people still use them both for their legacy applications.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 09/01/2020 10:15, Alex Peshkoff via Firebird-devel wrote:
> On 2020-01-09 16:10, Adriano dos Santos Fernandes wrote:
>> Better IMO: remove GPRE (and QLI) from the kits.
>
> As far as I know people still use them both for their legacy
> applications.
>
So it would be good to also know:
- How ma
09.01.2020 14:37, Adriano dos Santos Fernandes wrote:
- If they want to use not-updated tools, why they need to get these
tools from fresh versions?
For this question there is a simple answer: because these utilities are
version-dependent.
--
WBR, SD.
Firebird-Devel mailing list, web i
09.01.2020 13:53, Paul Reeves wrote:
So the question should whether to include dynamic gpre examples in the
packages or just remove them from the repo. As far as I know they have been
deprecated for a long while and have not been shipped in the product since
maybe even InterBase days.
On the
On Thu, 9 Jan 2020 15:42:50 +0100
Dimitry Sibiryakov wrote:
> 09.01.2020 13:53, Paul Reeves wrote:
> > So the question should whether to include dynamic gpre examples in the
> > packages or just remove them from the repo. As far as I know they have
> > been deprecated for a long while and have no
09.01.2020 16:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I may agree re. QLI (starting with FB4), but GPRE is known to be still
used. And yes, they're sponsors ;-) That said, I suppose GPRE will also
disappear one day, just later.
Dmitry
Fir
09.01.2020 16:26, Paul Reeves wrote:
CMakeLists.txt is not the definitive package list. It is just for CMake,
isn't it?
Yes. But it (and also script in build_win32) are shipped in the packages and supposed
to be used to build the examples after installation AFAIU. Both of them refer dyn and
On 2020-01-09 14:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I don't really see why we should remove it right now. Firebird still
relies on GPRE for its own build, so in that sense, GPRE isn't
deprecated. And people still use GPRE, so removing it w
On 2020-01-10 11:24, Mark Rotteveel wrote:
On 2020-01-09 14:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I don't really see why we should remove it right now. Firebird still
relies on GPRE for its own build, so in that sense, GPRE isn't
deprecated.
On 2020-01-10 09:57, Alex Peshkoff via Firebird-devel wrote:
On 2020-01-10 11:24, Mark Rotteveel wrote:
On 2020-01-09 14:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I don't really see why we should remove it right now. Firebird still
relies on GPR
10.01.2020 15:17, Mark Rotteveel wrote:
My intent was more that if we remove it, that we should at least first
explicitly deprecate it and announce removal, and not just remove it
right now.
Agreed.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/
If we forget that GPRE is used in the core, GPRE is just an utility that
calls the standard API and is not being updated with features or bug fixes.
It could be split to another sub-project and built. The built version
will probably work with whatever client/server is installed and will not
requir
15 matches
Mail list logo
