Created attachment 144451 [details] freebsd_ports_devel_libftdi1.shar.txt New port: devel/libftdi1 This is a new port for libftdi - library major version 1 This port is meant to co-exist with the existing devel/libftdi (library major version 0) /Uffe
Any news ?
Again with the PORTREVISION=1 line. The default is no PORTREVISION definition, so that's what I expect with a new port port: no PORTREVISION defined. Other than that, it's stage friendly and seems relatively fresh. another hint: When submitting a new port, at least post the contents of the pkg-descr in the PR description. You want to entice the committer by showing him/her why this port is a valuable addition to the tree. At least tell him what the port is used for.
Based on bug 179854, I'd like to see test logs first. Moving back to in-discussion.
Created attachment 145270 [details] libftdi1.shar.txt
Created attachment 145271 [details] libftdi1-1.1.log
Web rebuild --------------------------------------------------------------------- Build ID: 20140802184528-56197 Job owner: uffe Buildtime: 32 minutes Enddate: Sat, 02 Aug 2014 19:17:05 GMT Revision: 29946 Repository: https://redports.org/changeset/29946 --------------------------------------------------------------------- Port: devel/libftdi1 1.1 Buildgroup: 10.0-RELEASE/amd64 Buildstatus: SUCCESS Log: https://redports.org//~uffe/20140802184528-56197-229399/libftdi1-1.1.log Buildgroup: 10.0-RELEASE/i386 Buildstatus: SUCCESS Log: https://redports.org//~uffe/20140802184528-56197-229400/libftdi1-1.1.log Buildgroup: 9.2-RELEASE/amd64 Buildstatus: SUCCESS Log: https://redports.org//~uffe/20140802184528-56197-229401/libftdi1-1.1.log Buildgroup: 9.2-RELEASE/i386 Buildstatus: SUCCESS Log: https://redports.org//~uffe/20140802184528-56197-229402/libftdi1-1.1.log Buildgroup: 8.4-RELEASE/amd64 Buildstatus: SUCCESS Log: https://redports.org//~uffe/20140802184528-56197-229403/libftdi1-1.1.log Buildgroup: 8.4-RELEASE/i386 Buildstatus: SUCCESS Log: https://redports.org//~uffe/20140802184528-56197-229404/libftdi1-1.1.log Buildarchive URL: <https://redports.org/buildarchive/20140802184528-56197> redports <https://redports.org/>
from the attached full testport log ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for directories owned by MTREEs ===> Checking for directories handled by dependencies ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done
Perfect!
I'm testing devel/libftdi1 right now and the build conflicts with an installed devel/libftdi: /usr/local/home/pi/myp/devel/libftdi1/work/libftdi1-1.1/examples/find_all_pp.cpp:49:47: error: too many arguments to function call, expected 2, have 3 List* list = List::find_all(context, vid, pid); ~~~~~~~~~~~~~~ ^~~ /usr/local/include/ftdi.hpp:180:5: note: 'find_all' declared here static List* find_all(int vendor, int product); ^ 1 error generated.
(In reply to Kurt Jaeger from comment #9) > I'm testing devel/libftdi1 right now and the build > conflicts with an installed devel/libftdi: > It certainly should not conflict - I'll test to see if I can reproduce this
(In reply to Kurt Jaeger from comment #9) > I'm testing devel/libftdi1 right now and the build > conflicts with an installed devel/libftdi: > I've now tried to reproduce this but cannot - can you give some more details ? From your report I can clearly see what went wrong the wrong ftdi.h header file is picked up (/usr/local/include/ftdi.h) - but I'm having a hard time figuring out how that should happen - the Makefiles genreated by cmake explicitly setup internal include paths as the first thing. Do you have something that overload the include path ? Make.conf ?
(In reply to uffe from comment #11) > (In reply to Kurt Jaeger from comment #9) > > I'm testing devel/libftdi1 right now and the build > > conflicts with an installed devel/libftdi: > can you give some more details ? > > From your report I can clearly see what went wrong the wrong ftdi.h header > file is picked up (/usr/local/include/ftdi.h) - but I'm having a hard time > figuring out how that should happen - the Makefiles genreated by cmake > explicitly setup internal include paths as the first thing. > Do you have something that overload the include path ? Make.conf ? Not that I'm aware of. Here's work/libftdi1-1.1/examples/CMakeFiles/find_all_pp.dir/flags.make -------- CXX_FLAGS = -O2 -pipe -I/usr/local/home/pi/myp/devel/libftdi1/work/libftdi1-1.1/src -I/usr/local/include -fno-strict-aliasing -I/usr/local/include -O2 -pipe -I/usr/local/home/pi/myp/devel/libftdi1/work/libftdi1-1.1/src -I/usr/local/include -fno-strict-aliasing -I/usr/local/include -I/usr/local/home/pi/myp/devel/libftdi1/work/libftdi1-1.1/src -I/usr/local/include -I/usr/local/home/pi/myp/devel/libftdi1/work/libftdi1-1.1/ftdipp -I/usr/local/home/pi/myp/devel/libftdi1/work/libftdi1-1.1/examples -Wall -------- It definitly has WRKSRC/src before /usr/local/include/, but it needs to have ftdipp before /usr/local/include, as well.
(In reply to Kurt Jaeger from comment #12) > > It definitly has WRKSRC/src before /usr/local/include/, but it needs to have > ftdipp before /usr/local/include, as well. You are right - why did it not hit me ?
(In reply to uffe from comment #13) > (In reply to Kurt Jaeger from comment #12) > > > > It definitly has WRKSRC/src before /usr/local/include/, but it needs to have > > ftdipp before /usr/local/include, as well. > > You are right - why did it not hit me ? Let me answer this question myself... I'm using the pre-build libftdi package - it does not contain the ftdi.hpp because the options are off by default - which I think is wrong - but that is another case. I guess that you are using libftdi build from ports - with BOOST on ?
> I guess that you are using libftdi build from ports - with BOOST on ? Ah, yes, that's the reason I have that include file. Sorry, I should have mentioned it. General software development rule: options are bad(tm).
(In reply to Kurt Jaeger from comment #15) > > I guess that you are using libftdi build from ports - with BOOST on ? > > Ah, yes, that's the reason I have that include file. Sorry, I should > have mentioned it. General software development rule: options are bad(tm). Not worry - I'm currently running a new version of this one through poudriere - it had a fix for this case
Created attachment 145321 [details] libftdi1.shar.txt
Created attachment 145322 [details] libftdi1-1.1.log
new shar uploaded - fixes inclide path for example find_all_pp BTW the /usr/local/include path was the path for boost - it is now pushed to the back.
A commit references this bug: Author: pi Date: Sun Aug 3 21:35:44 UTC 2014 New revision: 363939 URL: http://svnweb.freebsd.org/changeset/ports/363939 Log: New port: devel/libftdi1 Talking to FTDI's FT2232C, FT232BM and FT245BM type chips including the popular bitbang mode, using libusb. WWW: http://www.intra2net.com/en/developer/libftdi/ Please note that this is an updated version of devel/libftdi, but dependencies require both versions to be available for a while. PR: 191656 Submitted by: uffe@uffe.org Changes: head/devel/Makefile head/devel/libftdi1/ head/devel/libftdi1/Makefile head/devel/libftdi1/distinfo head/devel/libftdi1/files/ head/devel/libftdi1/files/patch-CMakeLists.txt head/devel/libftdi1/files/patch-cmake__FindUSB1.cmake head/devel/libftdi1/files/patch-examples__CMakeLists.txt head/devel/libftdi1/pkg-descr head/devel/libftdi1/pkg-plist
Committed with very minor changes. Thanks very much!