Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freehdl : GPLed free VHDL https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178709 ------- Additional Comments From rc040203@xxxxxxxxxx 2006-01-26 03:01 EST ------- (In reply to comment #14) > (In reply to comment #13) > ... > > > I think it's not relevant with this package. > > What makes you think so? I disagree on this. > > If these files are host development files (very likely), then they should go to > > a *-devel package, if these files are target development files they are > > miss-places. I'd suggest you to implement a *-devel package. > > I don't know what to do about it! at the beginning i have implemented a devel > package but contacting upstream and comparing with ghdl > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172547) leads me to make > only one package as for a compliler. All these files are needed by freehdl to be > compiled with gcc. I'm not a specialist with this so i would like to have more > opinions. I don't know about ghdl, and can't comment on it. May-be it's carelessly packaged - I don't know. However, that's why I asked if these files are host (linux) or target (vhdl) files. If these are target files, they must be shipped as part of the application package, but must be moved out of the standard include/library paths . If these are host files and specify the API to the libraries inside of the library package, then these files belong into a devel package. If the applications (compiler) require the headers and/or libraries, then it proably would be best to split the package into 3 subpackages, say apps, devel and libs. Unfortunately, I am not familiar with this package's details and also could not find any example on how to use it. Do you have a pointer to an example? This would help clarifying this point. > > Besides this, there are further minor issues: > > * freehdl-config --cxxflags returns -I/usr/include > > * freehdl-config --ldflags returns -L/usr/lib > > I'm not sure to see where the problem is. the returns seems fine for me. no ? No, /usr/lib and /usr/include are on the system include/library paths in GCC. Therefore, explicitly passing them to the compiler always is a bug because it interferes with the system include/library paths (cf. -isystem in gcc.info rsp. man gcc). Should a package require them, its design is broken. > > * Some of the doc files aren't utf-8 nor asci encoded (German umlauts, probably > > iso8859-1 or iso8859-15 encoded). > > You are right. How to solve this ? Apply iconv ("iconv -f iso8859-1 -t utf-8") to the source files somewhere inside of the spec (e.g. in %prep). Alternatively, you could do this outside of the spec and apply a patch. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
