Re: Progress on AppVeyour

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.

On Fri, Jun 19, 2015 at 9:49 PM, Frediano Ziglio <[email protected]> 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.

> - 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.)

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.

> - 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.

>
> 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.

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>

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