Hello, I have got a few vacation days now, thank you for the tries which you documented recently.
I began yesterday with some exploratory work: - rewrote the script get-kicad.sh; this one keeps the principles of the former one, which are : source packages from three difference locations are put together in one package, the core at the root, documentation in the subdirectory doc/, and libraries in the subdirectory library/. - by the way, I mimicked upstream authors' download script in order to download all .pretty files, in alphabetic order into the subdirectory library/ - I created a Makefile to build documentation stuff in the subdirectory doc/build : this does the work in approximately two hours. Another Makefile in the top directory is used to build the core into ./build/ - I was touched by the issue which you already mentioned : building the core of Kicad depends on "calling home" to sourceforge, to get the release 1.54.0 of Boost libraries. I quilt-patched the file CMakeModules/download_boost.cmake to make it work quite like the script download_avhttp.cmake in the same directory: instead of downloading Boost's archive from Internet, a local copy is used. I shall include this copy into the debian source package, by adding one operation more in the script get-kicad.sh - I tried to replace the archive of the version 1.54.0 from sourceforge.net by DFSG complying source files (the .orig.tar.gz files), but infortunately nor the source file in Stretch (version 1.58.0), neither the file in Jessie (version 1.55.0) are consistently patched during Kicad's build process, and that process fails miserably. - building the core of Kicad is longer, but straightforward (approx. half a day), when done with gcc-4.9 - I suppose that there is less work to be done to configure Kicad's components libraries ... however I did not begin this part of the work yet. ----------------------------------------- As far as I can know, the longest task for me will be to check thoroughly copyright notices included in Kicad's core, documentation and libraries, and build the file debian/copyright. Another possibly annoying task would be to check whether the Boost package from upstream must be stripped down a little to make it DFSG-compliant, without touching files which are unseful for Kicad's build. Another task, probably lighter if I can do it wisely, is to constrain Kicad to comply with the FHS, that is, put architecture-independant data files in /usr/share, architecture-dependent stuff in /usr/lib, and user-level commands in /usr/bin. I read that you found hardcoded data locations in Kicad's core source. Do you estimate that changing the hardcoded paths will be a long task? Thank you for every hep so far. Best regards, Georges. Bas Wijnen a écrit : > On Thu, Oct 22, 2015 at 04:10:58PM +0200, Nick Østergaard wrote: > > 2015-10-21 19:39 GMT+02:00 Bas Wijnen <wij...@debian.org>: > > > The default library path mentions lots of things on github (but it > > > doesn't seem > > > to look there, which is good). It doesn't include the files from > > > kicad-common > > > in /usr/share. Adding them manually works well, but it would be nicer if > > > they > > > were enabled by default. > > > > > > When running cvpcb from eeschema, eeschema hangs and nothing happens. > > > > Is your footprint library table full of github refferenced libraries? > > If so a delay of a hand full of seconds is expected, depending on your > > connectivity. Be aware the github plugin does not seem to work if > > behind a proxy. :( > > You are right. Or at least it works after removing them. So it seems it does > look there. Github has been really slow lately, and my internet connection is > pretty slow anyway, so even though I waited longer than a few seconds, it > makes > sense that I should have waited several minutes. > > In any case, the Debian package should not come with those github libraries > enabled by default. That would be considered "phoning home", and it is not > allowed. Having an option for the user to easily add them would be > acceptable, > but I'm not sure if we want that; if the package is regularly updated, getting > the libraries from Debian's servers should not be a problem for most people > (and the ones who do want the github sources can still add them manually). > > > > I had a program set up for generating .net and .cmp files as well, so I > > > wouldn't need to use eeschema or cvpcb. However, pcbnew doesn't > > > recognize the > > > footprints I'm requesting, so perhaps my .cmp file is broken. I have no > > > way to > > > check what is wrong though, because cvpcb doesn't work. > > Ah, I see .cmp files are no longer used. I changed my program to add the > information to the .net file and now it works again. > > Thanks, > Bas > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
