libphidget-devel Mailing List for Phidget Library (Page 6)
Status: Alpha
Brought to you by:
jstrohm
Menu
▾
▴
libphidget-devel — Mailing list for developers of libphidget
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(134) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(11) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Vadim T. <vt...@fr...> - 2002-09-09 10:08:05
|
Hello, Which include files have to be exposed to the library users? OK, from the C side it's phidget.h, what about C++? Some of them are private, right? Does it make sense to separate the C headers from C++ headers at the deployment location (--prefix)? My guess is no. --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-09 09:45:12
|
Hello, Be careful with this animal - there's a bug in indent that makes it reformat some code on *every* run - it flips it back and forth. To see it, do this: cvs get libphidget cvs diff (output should be null) make indent cvs diff (output is not null) make indent cvs diff (output is null again) So, until the root cause is found, be careful how many times do you run it ;) --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-09 08:51:23
|
Hello, Couple of things: - Check if the tarball that appears if you 'make dist' works for you. Unpack it in a different location (preferrably at a different box), and see if './configure && make install' works. - The package name in ./configure.in doesn't seem right to me, I've set it to 'phidget', but it rather should be 'libphidget', right? - Need to fix minor issues - like what if indent and/or rpm (not used yet) are not available on the box where tarball is unpacked? - Then, ready for the next release? --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-08 18:57:07
|
Jack Strohm wrote: > > > So it works for you, right? Time to 'make indent && cvs commit'? > > yep! Duck! --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-08 18:26:38
|
According to Jack Strohm: > phidget.h and phidget.c are in the project twice, any reason why? > > [jstrohm@vash libphidget]$find . -name phidget.h > ./src/libphidget/phidget.h > ./phidget.h > [jstrohm@vash libphidget]$find . -name phidget.c > ./src/libphidget/phidget.c > ./phidget.c > [jstrohm@vash libphidget]$ So was main.c. My goof, I've rm'd the files, but forgot to 'cvs remove' them, so they popped up at the next 'cvs update'. Fixed. --vt |
|
From: Jack S. <js...@ja...> - 2002-09-08 14:41:20
|
phidget.h and phidget.c are in the project twice, any reason why? [jstrohm@vash libphidget]$find . -name phidget.h ./src/libphidget/phidget.h ./phidget.h [jstrohm@vash libphidget]$find . -name phidget.c ./src/libphidget/phidget.c ./phidget.c [jstrohm@vash libphidget]$ |
|
From: Jack S. <js...@ja...> - 2002-09-08 13:54:10
|
On Sun, 2002-09-08 at 03:16, Vadim Tkachenko wrote: > According to Jack Strohm: > > > if I check something out, then run make indent-local, edit a few > > things. How do I check the code back in. > > > > make indent > > cvs commit > > > > if so, does that mean CVS will check every file into version control, > > because they all have changes (at least the data on the file has). > > > > Just wondering . . . > > The proper sequence is like this: > > cvs get/update > make indent-local > hack away > make indent > cvs commit ok. > > There'll be one massive commit because all the code has to be brought to > compliance, and then the diffs will become civilized. The only thing is to > just remember to do 'make indent' before 'cvs commit' ;) Along the Ant > lines, it may be a good idea to create 'make commit', though the usefulness > will be limited due to the fact that you may want to commit one file. > Another solution is to integrate the indentation with CVS, though I don't > remember how to do it and have to read the SourceForge docs again. > > Did 'make indent' break things on your boxes? I'm still wondering *why* does > it break the return statements the first time, but not subsequent... everything seemed to work for me. > > Another thing - I might make 'make indent' slower, but smarter - right now, > if I do it twice in a row, even though the files are identical, the > timestamp changes, and it'll recompile all the project. It's relatively easy > to avoid it. yeah > > So it works for you, right? Time to 'make indent && cvs commit'? yep! |
|
From: Vadim T. <vt...@fr...> - 2002-09-08 08:16:58
|
According to Jack Strohm: > if I check something out, then run make indent-local, edit a few > things. How do I check the code back in. > > make indent > cvs commit > > if so, does that mean CVS will check every file into version control, > because they all have changes (at least the data on the file has). > > Just wondering . . . The proper sequence is like this: cvs get/update make indent-local hack away make indent cvs commit There'll be one massive commit because all the code has to be brought to compliance, and then the diffs will become civilized. The only thing is to just remember to do 'make indent' before 'cvs commit' ;) Along the Ant lines, it may be a good idea to create 'make commit', though the usefulness will be limited due to the fact that you may want to commit one file. Another solution is to integrate the indentation with CVS, though I don't remember how to do it and have to read the SourceForge docs again. Did 'make indent' break things on your boxes? I'm still wondering *why* does it break the return statements the first time, but not subsequent... Another thing - I might make 'make indent' slower, but smarter - right now, if I do it twice in a row, even though the files are identical, the timestamp changes, and it'll recompile all the project. It's relatively easy to avoid it. So it works for you, right? Time to 'make indent && cvs commit'? --vt |
|
From: Jack S. <js...@ja...> - 2002-09-08 07:17:17
|
On Sat, 2002-09-07 at 23:09, Vadim Tkachenko wrote: > According to Jack Strohm: > > On Sat, 2002-09-07 at 21:29, Vadim Tkachenko wrote: > > > Hello, > > > > > > I'm going to introduce two top-level targets: > > > > > > make indent > > > make indent-local > > > > > > First one indents all the .c, .h and .cc files according to ./indent.rules > > > file content (so the CVS stays consistent), and the second will indent all > > > the files according to current user's $HOME/.indent.pro content. > > > > > sounds good to me. Have you worked with indent before? I haven't. > > Just a little bit, but reading the man page once, carefully, is enough. > > This is what I'll do: I'll commit the things *related* to indent, however, I > will not do 'make indent' before commiting the changes, so you have a chance > to play around with $HOME/.indent.pro and see what kind of indentaion you > like. > > As for the project, I'd say just go with --gnu-style... Maybe with minor > modifications. > > Funny thing, though, indent breaks the very long return statements in the > switch statement in phidget.c, so that has to be fixed manually - but just > the first time... how does this affect CVS. if I check something out, then run make indent-local, edit a few things. How do I check the code back in. make indent cvs commit if so, does that mean CVS will check every file into version control, because they all have changes (at least the data on the file has). Just wondering . . . |
|
From: Vadim T. <vt...@fr...> - 2002-09-08 04:09:39
|
According to Jack Strohm: > On Sat, 2002-09-07 at 21:29, Vadim Tkachenko wrote: > > Hello, > > > > I'm going to introduce two top-level targets: > > > > make indent > > make indent-local > > > > First one indents all the .c, .h and .cc files according to ./indent.rules > > file content (so the CVS stays consistent), and the second will indent all > > the files according to current user's $HOME/.indent.pro content. > > > sounds good to me. Have you worked with indent before? I haven't. Just a little bit, but reading the man page once, carefully, is enough. This is what I'll do: I'll commit the things *related* to indent, however, I will not do 'make indent' before commiting the changes, so you have a chance to play around with $HOME/.indent.pro and see what kind of indentaion you like. As for the project, I'd say just go with --gnu-style... Maybe with minor modifications. Funny thing, though, indent breaks the very long return statements in the switch statement in phidget.c, so that has to be fixed manually - but just the first time... --vt |
|
From: Jack S. <js...@ja...> - 2002-09-08 03:02:26
|
On Sat, 2002-09-07 at 21:29, Vadim Tkachenko wrote: > Hello, > > I'm going to introduce two top-level targets: > > make indent > make indent-local > > First one indents all the .c, .h and .cc files according to ./indent.rules > file content (so the CVS stays consistent), and the second will indent all > the files according to current user's $HOME/.indent.pro content. > sounds good to me. Have you worked with indent before? I haven't. |
|
From: Vadim T. <vt...@fr...> - 2002-09-08 02:29:24
|
Hello, I'm going to introduce two top-level targets: make indent make indent-local First one indents all the .c, .h and .cc files according to ./indent.rules file content (so the CVS stays consistent), and the second will indent all the files according to current user's $HOME/.indent.pro content. OK? --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-08 00:48:55
|
According to Jack Strohm: > > > I get this error after I updated and tried to clean. > > > > > > Making clean in examples > > > make[2]: Entering directory `/home/jstrohm/2/libphidget/src/examples' > > > make[2]: *** No rule to make target `clean'. Stop. > > > make[2]: Leaving directory `/home/jstrohm/2/libphidget/src/examples' > > > make[1]: *** [clean-recursive] Error 1 > > > make[1]: Leaving directory `/home/jstrohm/2/libphidget/src' > > > make: *** [clean-recursive] Error 1 > > > > Funny, this is what I get: > > > > test -z "phidget_c phidget_cpp" || rm -f phidget_c phidget_cpp > > rm -rf .libs _libs > > /bin/rm -f *~ .*~ > > rm -f *.o core *.core > > rm -f *.o > > rm -f *.lo > > > > Are you sure you're in the right branch? Try to get into a different > > directory, do 'cvs get libphidget', configure, make and then make clean - it > > should be fine. > > > > Not sure what the problem is, but it's working on my laptop fine. (the > prob showed up on my desktop). Looks good to me. Check the ./src/examples directory - if it is empty, you're in the wrong branch. --vt |
|
From: Jack S. <js...@ja...> - 2002-09-08 00:03:28
|
On Sat, 2002-09-07 at 18:41, Vadim Tkachenko wrote: > According to Jack Strohm: > > > I get this error after I updated and tried to clean. > > > > Making clean in examples > > make[2]: Entering directory `/home/jstrohm/2/libphidget/src/examples' > > make[2]: *** No rule to make target `clean'. Stop. > > make[2]: Leaving directory `/home/jstrohm/2/libphidget/src/examples' > > make[1]: *** [clean-recursive] Error 1 > > make[1]: Leaving directory `/home/jstrohm/2/libphidget/src' > > make: *** [clean-recursive] Error 1 > > Funny, this is what I get: > > test -z "phidget_c phidget_cpp" || rm -f phidget_c phidget_cpp > rm -rf .libs _libs > /bin/rm -f *~ .*~ > rm -f *.o core *.core > rm -f *.o > rm -f *.lo > > Are you sure you're in the right branch? Try to get into a different > directory, do 'cvs get libphidget', configure, make and then make clean - it > should be fine. > Not sure what the problem is, but it's working on my laptop fine. (the prob showed up on my desktop). Looks good to me. |
|
From: Vadim T. <vt...@fr...> - 2002-09-07 23:41:33
|
According to Jack Strohm: > I get this error after I updated and tried to clean. > > Making clean in examples > make[2]: Entering directory `/home/jstrohm/2/libphidget/src/examples' > make[2]: *** No rule to make target `clean'. Stop. > make[2]: Leaving directory `/home/jstrohm/2/libphidget/src/examples' > make[1]: *** [clean-recursive] Error 1 > make[1]: Leaving directory `/home/jstrohm/2/libphidget/src' > make: *** [clean-recursive] Error 1 Funny, this is what I get: test -z "phidget_c phidget_cpp" || rm -f phidget_c phidget_cpp rm -rf .libs _libs /bin/rm -f *~ .*~ rm -f *.o core *.core rm -f *.o rm -f *.lo Are you sure you're in the right branch? Try to get into a different directory, do 'cvs get libphidget', configure, make and then make clean - it should be fine. --vt |
|
From: Jack S. <js...@ja...> - 2002-09-07 22:23:20
|
I get this error after I updated and tried to clean. Making clean in examples make[2]: Entering directory `/home/jstrohm/2/libphidget/src/examples' make[2]: *** No rule to make target `clean'. Stop. make[2]: Leaving directory `/home/jstrohm/2/libphidget/src/examples' make[1]: *** [clean-recursive] Error 1 make[1]: Leaving directory `/home/jstrohm/2/libphidget/src' make: *** [clean-recursive] Error 1 |
|
From: Jack S. <js...@ja...> - 2002-09-07 21:57:00
|
On Sat, 2002-09-07 at 16:51, Vadim Tkachenko wrote:
> According to Jack Strohm:
>
> > > Yep, it was a C++ artifact - the declaration block should've been before the
> > > code...
> >
> > What do you mean?
>
> C requires *all* the variable declarations to go before the code, so now it
> looks like this:
>
> int t,count;
> struct phidget **phidgets;
>
> printf("----------------------------------------\n");
> printf("Phidgets Device driver test.\n\n\n");
>
> // Initialize libphiget, here is where the devices are actually retrieved by the library
> // We want the library to handle signals (passing it 1)
> phidgetInit(1);
>
> // Get an array of pointers to phidgets and a count of available phidgets
> phidgets=phidgetGetPhidgets(&count);
>
ahhh, man I'm getting senile, of course. Wonder why it's been compiling
for me?
|
|
From: Vadim T. <vt...@fr...> - 2002-09-07 21:51:10
|
According to Jack Strohm:
> > Yep, it was a C++ artifact - the declaration block should've been before the
> > code...
>
> What do you mean?
C requires *all* the variable declarations to go before the code, so now it
looks like this:
int t,count;
struct phidget **phidgets;
printf("----------------------------------------\n");
printf("Phidgets Device driver test.\n\n\n");
// Initialize libphiget, here is where the devices are actually retrieved by the library
// We want the library to handle signals (passing it 1)
phidgetInit(1);
// Get an array of pointers to phidgets and a count of available phidgets
phidgets=phidgetGetPhidgets(&count);
--vt
|
|
From: Jack S. <js...@ja...> - 2002-09-07 21:48:58
|
On Sat, 2002-09-07 at 16:45, Vadim Tkachenko wrote: > Hello, > > > gcc -DPACKAGE=\"phidget\" -DVERSION=\"0.1p0\" -DHAVE_DLFCN_H=1 > > -DHAVE_LIBUSB=1 -I. -I. -I../libphidget -L../libphidget -c phidget_c.c > > phidget_c.c: In function > > ain': > > phidget_c.c:31: parse error before `struct' > > phidget_c.c:39: `phidgets' undeclared (first use in this function) > > phidget_c.c:39: (Each undeclared identifier is reported only once > > phidget_c.c:39: for each function it appears in.) > > make[2]: *** [phidget_c.o] Error 1 > > Yep, it was a C++ artifact - the declaration block should've been before the > code... What do you mean? |
|
From: Jack S. <js...@ja...> - 2002-09-07 21:48:31
|
On Sat, 2002-09-07 at 16:15, Vadim Tkachenko wrote: > Hello, > > Here: > > gcc -DPACKAGE=\"phidget\" -DVERSION=\"0.1p0\" -DHAVE_DLFCN_H=1 > -DHAVE_LIBUSB=1 -I. -I. -I../libphidget -L../libphidget -c phidget_c.c > phidget_c.c: In function > ain': > phidget_c.c:31: parse error before `struct' > phidget_c.c:39: `phidgets' undeclared (first use in this function) > phidget_c.c:39: (Each undeclared identifier is reported only once > phidget_c.c:39: for each function it appears in.) > make[2]: *** [phidget_c.o] Error 1 > > Makefile.am: > > --------8<------------------------------------ > bin_PROGRAMS = phidget_c phidget_cpp > > phidget_c_SOURCES = phidget_c.c > > phidget_c_LDADD = ../libphidget/libphidget.la > phidget_c_DEPENDENCIES = ../libphidget/libphidget.la > > phidget_cpp_SOURCES = phidget_cpp.cpp > > phidget_cpp_LDADD = ../libphidget/libphidget++.la > phidget_cpp_DEPENDENCIES = ../libphidget/libphidget++.la > > CFLAGS = -I../libphidget -L../libphidget > CXXFLAGS = -I../libphidget -I../phidget++ -L../libphidget -L../phidget++ > --------8<------------------------------------ > > phidget_c.c is former main.c, phidget_cpp.cc is former main.cc - to avoid > the name clash. Nothing's been changed inside. > > Now, my guess at the error is that now it is being compiled strictly as C, > and therefore &count doesn't count as a valid expression. Is this right? Or > the problem is somewhere else? > > I don't want to commit the code that doesn't compile... &count should be fine. that's just getting the address of count. I saw the same error when I tried to compile it on another box I have that I just installed Gentoo on. I'll play around and see what's wrong. |
|
From: Vadim T. <vt...@fr...> - 2002-09-07 21:45:53
|
Hello, > gcc -DPACKAGE=\"phidget\" -DVERSION=\"0.1p0\" -DHAVE_DLFCN_H=1 > -DHAVE_LIBUSB=1 -I. -I. -I../libphidget -L../libphidget -c phidget_c.c > phidget_c.c: In function > ain': > phidget_c.c:31: parse error before `struct' > phidget_c.c:39: `phidgets' undeclared (first use in this function) > phidget_c.c:39: (Each undeclared identifier is reported only once > phidget_c.c:39: for each function it appears in.) > make[2]: *** [phidget_c.o] Error 1 Yep, it was a C++ artifact - the declaration block should've been before the code... --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-07 21:16:07
|
Hello,
Here:
gcc -DPACKAGE=\"phidget\" -DVERSION=\"0.1p0\" -DHAVE_DLFCN_H=1
-DHAVE_LIBUSB=1 -I. -I. -I../libphidget -L../libphidget -c phidget_c.c
phidget_c.c: In function
ain':
phidget_c.c:31: parse error before `struct'
phidget_c.c:39: `phidgets' undeclared (first use in this function)
phidget_c.c:39: (Each undeclared identifier is reported only once
phidget_c.c:39: for each function it appears in.)
make[2]: *** [phidget_c.o] Error 1
Makefile.am:
--------8<------------------------------------
bin_PROGRAMS = phidget_c phidget_cpp
phidget_c_SOURCES = phidget_c.c
phidget_c_LDADD = ../libphidget/libphidget.la
phidget_c_DEPENDENCIES = ../libphidget/libphidget.la
phidget_cpp_SOURCES = phidget_cpp.cpp
phidget_cpp_LDADD = ../libphidget/libphidget++.la
phidget_cpp_DEPENDENCIES = ../libphidget/libphidget++.la
CFLAGS = -I../libphidget -L../libphidget
CXXFLAGS = -I../libphidget -I../phidget++ -L../libphidget -L../phidget++
--------8<------------------------------------
phidget_c.c is former main.c, phidget_cpp.cc is former main.cc - to avoid
the name clash. Nothing's been changed inside.
Now, my guess at the error is that now it is being compiled strictly as C,
and therefore &count doesn't count as a valid expression. Is this right? Or
the problem is somewhere else?
I don't want to commit the code that doesn't compile...
--vt
|
|
From: Jack S. <js...@ja...> - 2002-09-07 20:37:44
|
On Sat, 2002-09-07 at 15:21, Vadim Tkachenko wrote: > According to Jack Strohm: > > > Come to think of it, the phidgets code will always be a library - would it > > > be C or C++... right? So, to make this stuff more clear, I'd do this: > > > > > > ./src/libphidget C library > > > ./src/phidget++ C++ library > > > ./src/examples everything else > > > > > > > good idea. > > OK, I'll fix the makefiles, meanwhile, tell me which ones are the examples. > I'd guess whatever is there with main() is an example. Same for main.c in > ./src/libphidget. just 2 examples. One just uses libphidget.so and it's main.c the other is main.cc (I'm calling the executable phidgets) it requires libphidget.so and libphidget++.so (which isn't being generated now). |
|
From: Vadim T. <vt...@fr...> - 2002-09-07 20:21:49
|
According to Jack Strohm: > > Come to think of it, the phidgets code will always be a library - would it > > be C or C++... right? So, to make this stuff more clear, I'd do this: > > > > ./src/libphidget C library > > ./src/phidget++ C++ library > > ./src/examples everything else > > > > good idea. OK, I'll fix the makefiles, meanwhile, tell me which ones are the examples. I'd guess whatever is there with main() is an example. Same for main.c in ./src/libphidget. --vt |
|
From: Jack S. <js...@ja...> - 2002-09-07 20:19:40
|
On Sat, 2002-09-07 at 15:17, Vadim Tkachenko wrote: > Hello, > > Come to think of it, the phidgets code will always be a library - would it > be C or C++... right? So, to make this stuff more clear, I'd do this: > > ./src/libphidget C library > ./src/phidget++ C++ library > ./src/examples everything else > good idea. |
