FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2015-07-11 1:01 GMT+01:00 Ramiro Morales <cramm0 AT gmail.com>:
> Hi Frediano,
>
> Sorry for such a belated reply. Life insists on keeping me away from
> having fun with this. Thanks for making me realise I never posted to
> the list.
>

No problem, I'm quite busy too.

> On Fri, Jun 19, 2015 at 9:49 PM, Frediano Ziglio <freddy77 AT gmail.com> wrote:
>> Hi Ramiro,
>>   I'm following your progress on AppVeyor, quite interesting.
>>
>> Some things I notes:
>> - you register odbc driver with odbcconf, you can use regsvr32, the
>> driver should be able to register itself. Strange to use this program
>> for registering an odbc driver instead of a COM component but I added
>> this feature;
>
> Actually I tried the regsrv32 path but it fails for some reason I
> can't understand (IIRC OS reported error level 3), that's why the
> [1]relevant line is commented out. The lines below it (the ones that
> execute dbconf.exe) aren't sucessful either, as I uderstand they also
> try to register the driver with the ODBC manager. I copied all this
> from old posts to this list.
>

Weird. By the way I implemented some registration in odbc tests like
for unixODBC. Basically a temporary "odbc.ini" is created with a dummy
DSN pointing at freetds.conf section. Should work as long as tests are
able to find the driver.

>> - iconv seems not compiled (as tsql output), looks like some checks
>> are not done in CMakeLists.txt and so some variable are not defined
>> correctly;
>
> Exactly, I managed to get iconv to get linked in by using the
> win-iconv project but the [2]technique I used is too hacky and that's
> why I haven't proposed it (hacky = too windows-specific and too
> win-iconv-specific.)
>

Today I was fighting with win-iconv (there is a package ready in
fedora) and MingW trying to use the static version... well... libtool
finally won this round.

> Actually, I set up thing such that if openssl or iconv aren't
> available the build doen'st fail and CMake proceeds to buld FreeTDS
> with these features turned off. That's what's happening.
>
> I have some work in progress to get iconv (GNU libiconv, win-iconv)
> detected and linked in when using CMake by grabbing ideas and snippets
> from multiple sources around the Net. Unfortunately a module that
> performs such detection hasn't been added yet to CMake itself even
> when people has been proposing it for something like the last seven
> years.
>
> If/when we add it to our CMakeLists.txt then it will find and link in
> the win-iconv copy we already build on AppVeyor.
>

Good!

>> - similar for ODBC, on 64 bit for instance you get lot of problems as
>> some define are not there (like HAVE_SQLLEN). Not your fault but can
>> cause problems.
>
> Ok, in fact 64 bit ODBC stuff can be completely borked because I
> didn't care about ii at all, hoping to get the basic ODBC stuff
> working at leats with one configuration first.
>

They should be fixed now.

>>
>> I also added a fix for thread declatation, I'll look forward to see
>> results from next compile with updated master to to check if they
>> disappeared. It's a pity a thread returns a DWORD instead of a
>> DWORD_PTR it's useful to pass a pointerand thread process data passes
>> and return other data with another pointer.
>
> Thanks for your continued work on master. I see you are already
> planning a second release this year. Wow.
>

Well, with all tests and changes that are going on is time for a 1.x

> While we are at the AppVeyor Window CI builds topic and now that the
> needed files are alredy in the tree I'd like to suggest a remaining
> step I described in a [3]comment to the Pull Request:
>
> <quote>
> Note: If/when this gets merged, an account needs to be created in
> Appveyor by a GitHub FreeTDS organization member/owner (possibly using
> GitHub credentials) and then project settings on Appveyor need to be
> changed so it scans for the appveyor.yml file in the misc/ subdir
> instead of the source tree root.
>
> This would be the only Web UI action needed. Everything else can be
> handled with the appveyor.yml file.
> </quote>
>

Sure!

> Doing this would give us builds that are automatically triggered on
> AppVeyor under the FreeTDS account from every new commit/PR (and
> having the build results getting reported in the GitHub UI) without
> having to rely on me manually rebasing my ramiro/appveyor branch on
> master from time to time and getting these build/results under my
> personal account/URL hierarchy.
>
> Regards,
>
>
> 1. 
> https://github.com/ramiro/freetds/blob/e138e8c410cb4ce1f943975b5018c69c82521a67/misc/appveyor.yml#L103
> 2. 
> https://github.com/ramiro/freetds/commit/e19d808d25042cd551d42ca51db259ccab8ffdca
> 3. https://github.com/FreeTDS/freetds/pull/14#issuecomment-111882545
>
> --
> Ramiro Morales
> @ramiromorales

I should put your effort as a TODO for next release

bye
  Frediano