Re: [opensc-internal] building beta 1 right now ...

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [opensc-internal] building beta 1 right now ...

Andreas Jellinghaus-2
[moved to opensc-devel]

On Monday 26 September 2005 11:05, [hidden email] wrote:

> > You are right, QuickStart needs an onverhaul. Also martin paljak
> > mentioned the issue with Apple. Do you know their header files?
> > can we move from -I/usr/include #include <PCSC/*> to
> > -I/usr/include/PCSC #include <*>, or will that break something?
>
> The idea is to do the reverse. Change #include <*> by #include <PCSC/*>
>
> The problem is that:
> - Apple uses #include <PCSC/winscard.h>
> - Windows uses #include <winscard.h>
> - pcsc-lite is supposed to be source compatible with Windows API.
> I don't know how to satisfy everybody.

let's write a configure test for that, and define something appropriate.
so we can replace the #ifdef __APPLE__ with #ifdef HAVE_PCSC_INCLUDE
(or whatever name fits). that should make martin / all users of upstream
pcsc-lite on mac os X happy.

> You can't remove an installed package on an autobuilder (a computer used to
> automatically rebuild Debian packages). In general pcsc-lite is not
> installed on such machine but I think you get the idea.

autobuilders do not clean up? they install packages as needed to compile
something and then not remove them afterwards? sorry, but I think such
a system would be very badly designed and horribly broken. if so, the
debian maintainer can deal with it by patching, but the few debian
autobuilders are no reason for a general configure change.

> You have a summary but that is not useful when you build a rpm or deb
> package since you generaly do not watch ./configure output. Every thing is
> automatic until an error occurs, in general after every thing is compiled.

but debian has source and binary dependencies. do they have source conflicts?
(i.e. source abcd may not be installed?).

we should design the build/configure system to make it easiest for the
average source user, including the maintainer of those packages. so
is that a requirement for those only (they know well what to do)
or not? putting
if test -f /usr/include/PCSC; then echo "PLEASE REMOVE PCSC-LITE!"; exit 1; fi
into some spec file / or debian/rules file is not worth some more complex
statement in configure, I think. they can solve the problems easier than we
do, so why should we fix it?

> > your patch in detail:
> > a) add AC_ARG_WITH(pcsclite,...)
> > b) special handling for /usr/local/lib/pkgconfig/libpcsclite.pc
> > c) additional check for winscard.h
> > d) additional check for SCardEstablishContext
> > e) extra parameter for AM_CONDITIONAL
> >
> > I'm not sure about a). I dislike it and would prefer without.
> >
> > I don't like b, I thinkt improving the documentation is better than
> > adding more and more special cases to the configure code. we would
> > need to have that for each pkg-config check to be honest.
>
> pcsc-lite is installed in /usr/local/ by default. I agree with you that it
> adds complexity. A better solution would be to patch pkg-config to also
> check /usr/local/lib/pkgconfig/
> Remove b.

what about handling this in the documentation?

for example I think that /etc/opensc.conf is a much better place
than /usr/etc/opensc.conf or /usr/local/etc/opensc.conf.
still I prefer a lot to write into the documentation

to compile opensc:
export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig
./configure --prefix=/usr --sysconfdir=/etc
make
make install

if you want to compile with pc/sc-lite support, and it is not found
(for example on suse 9.3), you might want to set first:
export PCSC_CFLAGS="-I/usr/local/include/PCSC"
export PCSC_LIBS="-L/usr/local/lib -lpcsclite"

than to do rather ugly changes in configure to change defaults.


>
> > I would prefer without c and d. People always can shoot themself in
> > their foot if they want, no use trying to prevent it. do you know of
> > any distribution that shipps a broken pcsc-lite? i.e. libpcscslite.pc
> > in the normal package? or broken header files or library files?
> > what exactly is your scenarion for this test to find something?
> > (except people manualy giving wrong PCSC_LIBS/PCSC_CFLAGS?)
>
> As I said SuSE 9.3 (latest version?) does not provide libpcsclite.pc in
> their pcsc-lite package.

bummer. sorry, didn't know that. argh. do they ship such an old version that
did not include that file, or did they forget to put the file into the
package?

> So the user has to provide PCSC_LIBS/PCSC_CFLAGS by hand. I just try to help
> him use the correct values and detect errors as early as possible.

I know fixing it in configure code could be better than fixing it
documentation. but we have a long history of a huge, ugly and unmaintainable
configure code, and I was very happy to see it getting better.

I'm not 100% certain what is best to do. currently I tend towards better
documentation, as we need that anyway, and if it still doesn't work out,
we can mess with configure.

i.e. messing with configure does not relieve us of improving the documentation
concerning those parts.


so my suggestion is:
lets first get the documentation right. document all the things like configure
flags and registry keys and suse 9.3 broken and mac os X / apple deviating
from the norm and all that. see if it helps. we can still change configure,
but documentation is more important from my point of view.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: [opensc-internal] building beta 1 right now ...

Ludovic Rousseau
On 26/09/05, Andreas Jellinghaus <[hidden email]> wrote:

> On Monday 26 September 2005 11:05, [hidden email] wrote:
> > The problem is that:
> > - Apple uses #include <PCSC/winscard.h>
> > - Windows uses #include <winscard.h>
> > - pcsc-lite is supposed to be source compatible with Windows API.
> > I don't know how to satisfy everybody.
>
> let's write a configure test for that, and define something appropriate.
> so we can replace the #ifdef __APPLE__ with #ifdef HAVE_PCSC_INCLUDE
> (or whatever name fits). that should make martin / all users of upstream
> pcsc-lite on mac os X happy.

I don't see any better solution.
This will make the ./configure script a bit more complex :-)

> > You have a summary but that is not useful when you build a rpm or deb
> > package since you generaly do not watch ./configure output. Every thing is
> > automatic until an error occurs, in general after every thing is compiled.
>
> but debian has source and binary dependencies. do they have source conflicts?
> (i.e. source abcd may not be installed?).

No source conflicts but Build-Conflicts as we have Build-Depends.
I don't know if the same exist for RPM: the opposite of BuildRequires.

> we should design the build/configure system to make it easiest for the
> average source user, including the maintainer of those packages. so
> is that a requirement for those only (they know well what to do)
> or not? putting
> if test -f /usr/include/PCSC; then echo "PLEASE REMOVE PCSC-LITE!"; exit 1; fi
> into some spec file / or debian/rules file is not worth some more complex
> statement in configure, I think. they can solve the problems easier than we
> do, so why should we fix it?

A better way to avoid using pcsc-lite would be to use
PCSC_CFLAGS=-I/tmp (or something similar) so that the include files
are not found.
But that is an ugly hack I really dislike compared to
--without-pcsclite argument.

> > As I said SuSE 9.3 (latest version?) does not provide libpcsclite.pc in
> > their pcsc-lite package.
>
> bummer. sorry, didn't know that. argh. do they ship such an old version that
> did not include that file, or did they forget to put the file into the
> package?

SuSE 9.3 provides pcsc-lite-1.2.9-6.
They had pcsc-lite 1.2.0 in SuSE 9.2. I suspect they reused the .spec
file without too much editing. My name is not in the Authors: field of
the .spec file. Grrr! Anybody from SuSE here?

> > So the user has to provide PCSC_LIBS/PCSC_CFLAGS by hand. I just try to help
> > him use the correct values and detect errors as early as possible.
>
> I know fixing it in configure code could be better than fixing it
> documentation. but we have a long history of a huge, ugly and unmaintainable
> configure code, and I was very happy to see it getting better.
>
> I'm not 100% certain what is best to do. currently I tend towards better
> documentation, as we need that anyway, and if it still doesn't work out,
> we can mess with configure.

I try to automate things as much as possible. Users (including me) do
not read documentation unless they have to.

> i.e. messing with configure does not relieve us of improving the documentation
> concerning those parts.

Right.

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: [opensc-internal] building beta 1 right now ...

Andreas Jellinghaus-2
On Tuesday 27 September 2005 08:32, Ludovic Rousseau wrote:
> A better way to avoid using pcsc-lite would be to use
> PCSC_CFLAGS=-I/tmp (or something similar) so that the include files
> are not found.
> But that is an ugly hack I really dislike compared to
> --without-pcsclite argument.

my reading of the configure code: that won't work at all.
if you set PCSC_CFLAGS then automaticaly HAVE_PCSC is
defined, the value is not further checked.
so you will get a compile error, no matter whether or not
pcsc-lite is installed.

but I wonder: is this an abstract case or an actual use case?
do you have systems where pcsc-lite is installed, and does anyone
want to build a debian package without pcsc support?

> > I'm not 100% certain what is best to do. currently I tend towards better
> > documentation, as we need that anyway, and if it still doesn't work out,
> > we can mess with configure.
>
> I try to automate things as much as possible. Users (including me) do
> not read documentation unless they have to.

Often I find a few lines of documentation can save me from much more
code. I prefer documentation. And I try to keep it short and terse
so reading it is rewarding.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel