Re: [Kicad-developers] Finally!
On 5 October 2014 00:12, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. Unfortunately we've done it the other way around in rev 5174: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 This breaks KiCad-Winbuilder, but only for new downloads because it can't configure due to not being able to find the python libs. Old installs still work because pythonlibs were already found by the modified findpythonlibs module. I think the main problem is that Python-a-mingw-us which is used by KiCad-Winbuilder uses a different name for the python dll. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Finally!
On 15 October 2014 21:44, Wayne Stambaugh stambau...@verizon.net wrote: On 10/15/2014 4:27 PM, Brian Sidebotham wrote: On 5 October 2014 00:12, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. Unfortunately we've done it the other way around in rev 5174: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 This breaks KiCad-Winbuilder, but only for new downloads because it can't configure due to not being able to find the python libs. Old installs still work because pythonlibs were already found by the modified findpythonlibs module. I think the main problem is that Python-a-mingw-us which is used by KiCad-Winbuilder uses a different name for the python dll. Best Regards, Brian. It was worth a try. The problem with the stock FindPythonLibs.cmake is that it doesn't have a default variable (either environment or CMake definition) that allows you to add to the PATH statement in the find_library() command. This way you could just define the path during the build config because in your case you already know the path. I guess I'll have to put the custom version back and fix it so it works on MSYS2. Before I do that, what is the python-a-mingw-us link library path and file name? Maybe I can figure out a way to use the stock one with kicad-winbuilder without breaking the msys2 builds. Wayne I think the better way is for me to generate a new findpythonamingwus.cmake module which can exclusively find a python-a-mingw-us install. This can go in our custom cmakemodules directory and then we can either: if( PYTHON_NOFOUND ) FindPythonAMinGWUs() or if( MINGW AND NOT MSYS ) FindPythonAMinGWUs() to use findpythonamingwus instead of the stock findpython module. I agree using the standard install versions where we can is the best way. The reason you see if( MINGW ) clauses in the custom findpython module is because it was at the time the only sane option for building python modules with MinGW because otherwise you'd end up with multiple c runtimes linked which would cause havoc. Now that there is a pure MinGW version of python available under msys2 the if( MINGW ) clauses are not correct because you don't want to search for python-a-mingw-us when you're using msys2. Returning to the custom one until I introduce the new one would be the best solution for me. Our baby is currently cutting teeth so time is scarce for KiCad development at the moment, but I promise to get it sorted as soon as possible. It should just be a case of stripping down the custom version to stop it detecting a standard python install and to just look for the python-a-mingw-us install. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Finally!
On 15 October 2014 22:44, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 15 October 2014 21:44, Wayne Stambaugh stambau...@verizon.net wrote: On 10/15/2014 4:27 PM, Brian Sidebotham wrote: On 5 October 2014 00:12, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. Unfortunately we've done it the other way around in rev 5174: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 This breaks KiCad-Winbuilder, but only for new downloads because it can't configure due to not being able to find the python libs. Old installs still work because pythonlibs were already found by the modified findpythonlibs module. I think the main problem is that Python-a-mingw-us which is used by KiCad-Winbuilder uses a different name for the python dll. Best Regards, Brian. It was worth a try. The problem with the stock FindPythonLibs.cmake is that it doesn't have a default variable (either environment or CMake definition) that allows you to add to the PATH statement in the find_library() command. This way you could just define the path during the build config because in your case you already know the path. I guess I'll have to put the custom version back and fix it so it works on MSYS2. Before I do that, what is the python-a-mingw-us link library path and file name? Maybe I can figure out a way to use the stock one with kicad-winbuilder without breaking the msys2 builds. Wayne I think the better way is for me to generate a new findpythonamingwus.cmake module which can exclusively find a python-a-mingw-us install. This can go in our custom cmakemodules directory and then we can either: if( PYTHON_NOFOUND ) FindPythonAMinGWUs() or if( MINGW AND NOT MSYS ) FindPythonAMinGWUs() to use findpythonamingwus instead of the stock findpython module. I agree using the standard install versions where we can is the best way. The reason you see if( MINGW ) clauses in the custom findpython module is because it was at the time the only sane option for building python modules with MinGW because otherwise you'd end up with multiple c runtimes linked which would cause havoc. Now that there is a pure MinGW version of python available under msys2 the if( MINGW ) clauses are not correct because you don't want to search for python-a-mingw-us when you're using msys2. Returning to the custom one until I introduce the new one would be the best solution for me. Our baby is currently cutting teeth so time is scarce for KiCad development at the moment, but I promise to get it sorted as soon as possible. It should just be a case of stripping down the custom version to stop it detecting a standard python install and to just look for the python-a-mingw-us install. Best Regards, Brian. Also, SelectLibraryConfigurations.cmake is there purely for our old FindPythonLibs.cmake, so if that's gone, then SelectLibraryConfigurations.cmake can go too. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] eeschema: add Select button for footprints in single component field edits
Sorry, I didn't get much chance to look at it - but I liked the idea of it - I think this is one of the very reasons behind the KiWay work. It's certainly a bonus of that work which we should be reaping. I didn't get a chance to apply and test though. Let me know if you need that. Best Regards, Brian. On 14 October 2014 14:58, Wayne Stambaugh stambau...@verizon.net wrote: Has anyone else looked at this patch? If you haven't, it adds a select button that launches the footprint viewer to select a footprint to the edit field properties dialog when the footprint field is selected. I personally like it but since it's behavioral change I would like some input before I commit it. Thanks, Wayne On 10/11/2014 1:43 AM, Mark Roszko wrote: Hi, This patch makes the changes to add a selection button to the simple dialog that appears when you right-click on a component and choose Edit Component Footprint. The button will open the footprint browser. This is just like the component property editor having the assign footprint button. + Doxygenization of the class. This also works in the library editor when you click on the footprint text and go to edit it. Patches attached and a bazr branch submitted for merge. https://code.launchpad.net/~mark-roszko/kicad/eeschema_footprint_pick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Library Editor naming consistency
On 13 October 2014 17:22, Wayne Stambaugh stambau...@verizon.net wrote: On 10/12/2014 9:14 PM, Mark Roszko wrote: Very minor but the main KiCAD window calls it Schematic Library Editor, eeschema calls it Library Editor and the window itself is Parts Library Editor. Can the name be standardized? It might be better to just call it Component Library Editor because that's what the schematic symbols are called instead of Parts. Just like PCB Footprint Editor is for Footprints. The easy answer to your question is yes, the naming can and should be consistent. The hard part of your question is consistently what? This topic has been thoroughly discussed before. You will find there is really no consensus. Personally, I prefer symbol. When I think of parts or components, I think of the physical objects themselves. I don't actually place a resistor or an IC in a schematic. I place a symbolic representation of that component in my schematic. Dick's preference was part and he had valid justifications for his preference. He even renamed some of the Eeschema code object names from COMPONENT to PART. I really don't have a strong preference, that's why I never pushed the issue. I doubt you are going to get a consensus on this issue. You'll have to pick a term and live with the unhappy developers and users. Welcome to open source programming :). I think the manual should probably be the defacto standard, or at least the first place to look in these inconsistency issues. The manual uses component throughout and indeed Component name in the UI Component properties dialog. All the screenshots show Component too. If eeschema has changed these, they should be changed back. If a change is made, it'll have to also be rippled through the documentation which is a very heavy change and that in turn may cause the translators a headache too. Part is not a good candidate because, as per the manual we already have something designated a part and that is essentially the individual gates in the multi-gate IC. I find the description of parts per package a bit weird, it should really be Number of parts per component and Parts in component locked (cannot be swapped) Of course,it looks like the manual and editor are out-of-sync as the library editor refers to parts as units and components as parts. It can get so confusing when the two are not in sync! It'll take longer to fix the documentation compared to fixing the code most likely. I would call it Schematic Library Editor or else Component Library Editor, the latter probably being more accurate. I also don't have a strong opinion, but consistency is key. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Library Editor naming consistency
On 14 October 2014 21:54, Mark Roszko mark.ros...@gmail.com wrote: The manual uses component throughout and indeed Component name in the UI Component properties dialog. All the screenshots show Component too. If eeschema has changed these, they should be changed back An manual should never define the software, it should explain the software. Or else we'll never have new features or evolutions in feature sets. No, you do - you write the documentation first and then write the code. Then you know what's called what and how it's meant to work. Even if the documentation is a blueprint, or email or in this case the manual. As with all these things, it's just an opinion, but I nearly always start with the documentation and then write the code to suit. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Library Editor naming consistency
On 14 October 2014 21:57, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 14 October 2014 21:54, Mark Roszko mark.ros...@gmail.com wrote: The manual uses component throughout and indeed Component name in the UI Component properties dialog. All the screenshots show Component too. If eeschema has changed these, they should be changed back An manual should never define the software, it should explain the software. Or else we'll never have new features or evolutions in feature sets. No, you do - you write the documentation first and then write the code. Then you know what's called what and how it's meant to work. Even if the documentation is a blueprint, or email or in this case the manual. As with all these things, it's just an opinion, but I nearly always start with the documentation and then write the code to suit. Funnily enough, just about to commit, and then write the documentation to suit! lol Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Library Editor naming consistency
On 14 October 2014 22:16, Mark Roszko mark.ros...@gmail.com wrote: Be it just semantics but for me Documentation != Manual != Specifications It is probably just semantics, but then this is wrong because apparently Documentation != Manual !? I wish the manuals were plain text based, I would be more than happy to update documentation as I change things. I do it all the time with the Linux kernel patches I upstream where its a requirement ;) Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] eeschema: add Select button for footprints in single component field edits
On 14 October 2014 22:09, Mark Roszko mark.ros...@gmail.com wrote: Ah, the only thing that changed is I moved all the comments from the .cpp to .h as you asked before so you can't ding me for that :P And a description. There is a white space line I just noticed. I am having trouble with wxFormBuillder. I cannot find an ubuntu/debian compatible package that KiCAD uses anywhere. In fact it appears Debian somehow diverged from Ubuntu 14 package versions when I was messing around. Right now, I can get a wxFormBuilder from Ubuntu upstream that cannot open any KiCAD files, or use the latest Formbuilder PPA that is a revision ahead :/ I'm also using the same PPA because that's the only way to easily get wxFormBuilder on Ubuntu that can open the KiCad dialogs. Wayne, as I'm about to commit changes to eeschema/dialogs/eeschema/dialogs_eeschema_options_base.fbp with FileVersion 1.13 I quickly grepped the dialogs and there are quite a few dialogs at the same FileVersion; grep FileVersion -r . ./dialog_annotate_base.fbp:FileVersion major=1 minor=13 / ./dialog_bom_base.fbp:FileVersion major=1 minor=11 / ./dialog_choose_component_base.fbp:FileVersion major=1 minor=13 / ./dialog_edit_component_in_lib_base.fbp:FileVersion major=1 minor=11 / ./dialog_edit_component_in_schematic_fbp.fbp:FileVersion major=1 minor=11 / ./dialog_edit_label_base.fbp:FileVersion major=1 minor=11 / ./dialog_edit_libentry_fields_in_lib_base.fbp:FileVersion major=1 minor=11 / ./dialog_eeschema_config_fbp.fbp:FileVersion major=1 minor=13 / ./dialog_eeschema_options_base.fbp:FileVersion major=1 minor=13 / ./dialog_erc_base.fbp:FileVersion major=1 minor=13 / ./dialog_libedit_dimensions_base.fbp:FileVersion major=1 minor=11 / ./dialog_libedit_options_base.fbp:FileVersion major=1 minor=13 / ./dialog_lib_edit_draw_item.fbp:FileVersion major=1 minor=11 / ./dialog_lib_edit_pin_base.fbp:FileVersion major=1 minor=11 / ./dialog_lib_edit_text_base.fbp:FileVersion major=1 minor=13 / ./dialog_lib_new_component.fbp:FileVersion major=1 minor=11 / ./dialog_netlist_base.fbp:FileVersion major=1 minor=13 / ./dialog_plot_schematic_base.fbp:FileVersion major=1 minor=11 / ./dialog_print_using_printer_base.fbp:FileVersion major=1 minor=11 / ./dialog_sch_edit_sheet_pin_base.fbp:FileVersion major=1 minor=10 / ./dialog_sch_find.fbp:FileVersion major=1 minor=11 / ./dialog_sch_sheet_props.fbp:FileVersion major=1 minor=11 / Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Turn key build system for poking and messing around with the sources
On 9 October 2014 10:01, Benoît Roehr benoit.roehr...@gmail.com wrote: Le 09/10/2014 08:36, Lorenzo Marcantonio a écrit : On Wed, Oct 08, 2014 at 11:33:39PM +0200, Benoît Roehr wrote: Does someone have a turnkey solution for building and running eeschema alone ? Can it be done by tweaking winbuilder ? (help help !) Well, if you only touch eeschema the rebuild will only recompile that! So I see no needs for tweakings... You answered exactly my concern ! I was searching a way to speed up the compilation. Ok, so now, I'm digging into the cMake script to build kicad from local source. I'll find this I think. KiCad-Winbuilder is not a great way to develop code, but if you have it on your computer and you want to investigate the sources, you can at least do that. Once you've compiled once, use the enterenv.bat batch file to enter a console with the KiCad winbuilder environment setup. From here you can move to the build directory and use the command mingw32-make eeschema to build just eeschema, or else mingw32-make by itself to build everything (that requires building). Running make.bat is not going to be good if you're making local changes because you'll likely hit conflicts at some point and everything will become a mess. Just investigate and make changes, then when you want to update to the latest version of KiCad you can enter the kicad source directory and use bzr diff mychanges.diff to keep track of your changes in a diff file, followed by bzr revert to remove your changes from the tree. You can then safely run make.bat again to update and compile everything. As make.bat checks for the latest documentation and KiCad source code it is much quicker to enter the environment and issue the make commands directly. You'll have to run eeschema from the build directory, or else manually copy it across to the kicad\bin folder to use RunKiCad.bat Lastly, if you do want to develop KiCad I would strongly urge moving to Linux for development because it's just s much easier and faster! We always require heavy testing on Windows, but developing on Windows is a real pain. Good Luck anyway! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] Eeschema dialog tweaks
Hi Mark, Thanks for your work, I've not had a chance to look at the merge request. Generally discussion is always a great idea because it's hard to glean from a diff what the intended changes are and what the impact is going to be. I'm at work at the moment so still can't review the diff. I'm currently working on the eeschema options dialog to improve the template field names editor so please don't change that at the moment, otherwise you'll get conflicts in the .fbp file and they are a complete pain to sort out manually!! Best Regards, Brian. On 8 October 2014 05:39, Blair Bonnett blair.bonn...@gmail.com wrote: On 8 October 2014 17:34, Mark Roszko mark.ros...@gmail.com wrote: I was thinking it could be Total issues, Warnings, Errors, having the word count repeat 3 times seems...redundant. Total errors is also wrong since its warnings + errors. Sounds even better. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Finally!
On 5 October 2014 00:18, Wayne Stambaugh stambau...@verizon.net wrote: Here is a another teaser of the mingw64 version of kicad showing the wxPython shell so it appears to be working. Hi Wayne, There's no reason it shouldn't work really, KiCad-Winbuilder uses mingw-w64 and builds fine with wxPython (Well, the wxwidgets-cmake project I did for it: https://launchpad.net/wxwidgets-cmake ). By the way, is the MSYS python okay when not being run in a POSIX environment? I'm sure it is and in which case it removes the need for Python-a-mingw-us, but Python-a-mingw-us is still the only MinGW compiled python distribution outside of MSYS as far as I'm aware. This is obviously essential for us when packaging KiCad for windows. What we do need to think about when generating a stable release for Windows is the packaging of dependencies. Python brings with it a lot of dependency requirements. I don't think cpack will be able to handle our installer very well if we choose to include python (which I am assuming we will have to). I'm very glad to see you've got the python console up and running! :D Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Macro expansion in module text
On 6 October 2014 16:23, Wayne Stambaugh stambau...@verizon.net wrote: Lorenzo, I know it's a pain to do but this really needs to be documented somewhere in the Pcbnew user's manual. Otherwise, no one will know how to use this excellent feature except those of us on the developers mailing list. The reason I'm asking you to do this is that yesterday I was attempting use the BOM generator which I haven't used in a long time and discovered that the current documentation is completely different than the actual behavior of Eeschema. We *all* really need to do a better job of keeping the documentation current. I'm not singling you out Lorenzo but if we truly want to provide a stable release at some point in the near future then we really should keep the documentation current. If you add a new feature, change the way a current feature functions, or happen to stumble across an documentation error, please make sure the documentation gets updated. I know there is work under way to convert to a text based format but we should continue to keep the odt documentation up to date until that actually happens. Thanks, Wayne On 10/4/2014 11:26 AM, Lorenzo Marcantonio wrote: Sorry about the delay, we had the automechanika fair and related stuff to handle :P In fact the patch is quite simple (I already did the biggest changes...) It handles % sequences in user text primitives inside modules (usefulness already debated); now it recognizes: %% for a plain % %R inserts the reference %V inserts the value Obviously it can be extended to insert other stuff (has to be available from the module class, however). The only issue is repainting, since it insert a dependency between unrelated fields: when you change reference or value the user fields using them are not updated until the next redraw. Shouldn't be a big problem, however. Extensive testing is, as usual, appreciated. Have fun I know it was only a few lines of code Lorenzo, but you wrote them not me, so thank-you! I've had so little time to do anything lately and I really wanted to be able to do the assembly layer properly for a long time. Wayne, I agree and I am about to commit some changes to the EESCHEMA options dialog to improve the template field editing and some general tidy up with the code class. I was wondering if we should document this in the current docs or wait until the new docs. I will update the documentation as soon as the dialog changes are in place. I still need to add validation to the template field names too, but I will do that as a second patch because I'm running out of time and I've already had to deal with conflicts in the fbp generated XML once (it was a nightmare!) so I'm keen for that not to happen again. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] OS X build issue when rerunning CMake
On 6 October 2014 21:57, Wayne Stambaugh stambau...@verizon.net wrote: That was an easy fix :) Thanks again for taking on the task of providing regular builds for OSX users. Now we just have to get regular builds for windows users. I think once we get over this hurdle, we wont have to spend so much time providing help to users who really should not have to build from source to use a recent version of KiCad. I would rather our limited development resources be spent working on the KiCad source. Thanks, Wayne Hi Wayne, Milan has been using KiCad-Winbuilder and some excellent work of his own to provide KiCad packages: http://kicad.nosoftware.cz/ The latest one is only a few days old. I've cc'd him here. Hopefully he'll be willing to provide us with the necessary horsepower to provide regular KiCad builds, and/or share his experience with generating the Windows installer. He's done an absolutely brilliant job there. It's install and use!! The only thing we need to is to use start kicad rather than his kicad call in the batch file he's using to start kicad. This will then drop the dos box that's present when you run this KiCad. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Need help finding a git mirror for kicad/doc
Excellent work Marco. Sorry, replying on my phone! Picking the right tool is essential, we're just itching to make the transition to text based documentation, that's all. We've had odt documentation for a long time, and we can suffer that for a while longer while we evaluate the text based solutions. Thank-you so much for testing everything out, particularly testing the internationalization features supported by those functions, it's something where I have zero experience and I'm sure the translators will be very happy with an easier to use system! Thanks again! Brian. On 6 Oct 2014 22:09, Marco Ciampa ciam...@libero.it wrote: On Mon, Oct 06, 2014 at 12:13:30PM -0400, Wayne Stambaugh wrote: On 10/5/2014 11:26 PM, Mitch Davis wrote: Hi, On Mon, Oct 6, 2014 at 1:46 PM, Blair Bonnett blair.bonn...@gmail.com wrote: On 6 October 2014 14:33, Mitch Davis mjd+launchpad@afork.com wrote: Is there a git mirror for lp:~kicad-developers/kicad/doc? There is now: https://github.com/blairbonnett-mirrors/kicad-doc Thanks very much! I just did a git clone. Under 3 minutes. I think bzr would still be going... NB it is big (~800 MB) as most of the files are stored in binary form. There has been talk about switching to a text-based documentation source. Hopefully when this happens a new repository can be started (freezing the old one to retain the history) so its much smaller to obtain. Sounds good. I've been following the debate. +1 for Sphinx and reStructuredText. Sphinx looks like a reasonable candidate. It satisfies the criteria of being available on Linux, Windows, and OSX and there is even a link to an odt to Sphinx converter. Sphinx looks one of the few complete documentation packages I have tried. I onestly I do not like rest and prefer asciidoc instead but I think that sphinx is a wonderful piece of code and I have seen that most of the people that use rest use it because of sphinx and not viceversa. Besides asciidoc is only slightly different and simpler than rest so it is not so crucial choosing rest instead of asciidoc or markdown. See: - http://blog.ser1.net/2011/06/restructuredtext-vs-asciidoc.html - http://asciidoctor.org/docs/what-is-asciidoc/ (- this site is written in asciidoc!) I did a quick scan of the documentation and it seems like it provides all the features we would need to create high quality documentation. I don't know anything about Sphinx but I do like the fact that is markdown rather than docbook. Actually it is not markdown but rest (RE-Structured-texT) but it is just the same: a simpler and human readable format (like markdown or asciidoc) that could be converted into docbook easily and automatically. I've never found XML to be very readable. I agree, not at all. You have to have the assistance of powerful editors like emacs or eclipse to be able to be a docbook prolific writer. I'm depending on the experience of others to make this documentation conversion happen so all other interested parties please step forward with comments so that we can get this moving forward. I ask you all to please have the patience to wait just a little more. I have successfully and satisfactory converted the cvpcb manual either in asciidoc, markdown and rest and tested with various platforms (pandoc, asciidoc, asciidoctor, sphinx). BTW I haven't found an easy/satisfactory way to format the source file to obtain a pdf with the kicad logo image in the front cover ... if someone know how to do it I'm all ears... I just want to finish experimenting with what I care most: multilanguage support. I want to produce multilanguage versions of the manual creating various .po gettext files and re-merge those versions into many nationalized versions. I want to test it _before_ making the final decision about the tool to use. Do we have to choose this important tool quickly? I hope not... Thanks! -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Finally!
Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. I'm away from my keyboard at the moment so I'll have a look at this tomorrow when I'm back at the keyboard. Best Regards, Brian. On 4 Oct 2014 23:32, Wayne Stambaugh stambau...@verizon.net wrote: Thanks for the input. I give Brian and chance to reply. It may have been something just for the kicad-winbuilder so I may have to find an alternate solution that works in both cases. On 10/4/2014 6:21 PM, Blair Bonnett wrote: On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Macro expansion in module text
Hi Lorenzo, Thanks for sorting this out, it'll make a great difference for my next board! Best Regards, Brian. On 4 Oct 2014 16:26, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: Sorry about the delay, we had the automechanika fair and related stuff to handle :P In fact the patch is quite simple (I already did the biggest changes...) It handles % sequences in user text primitives inside modules (usefulness already debated); now it recognizes: %% for a plain % %R inserts the reference %V inserts the value Obviously it can be extended to insert other stuff (has to be available from the module class, however). The only issue is repainting, since it insert a dependency between unrelated fields: when you change reference or value the user fields using them are not updated until the next redraw. Shouldn't be a big problem, however. Extensive testing is, as usual, appreciated. Have fun -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Layer for reference and value text
On 14 September 2014 06:17, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Sun, Sep 14, 2014 at 12:39:33AM -0400, Carl Poirier wrote: Is there any way to have it not on silkscreen, besides editing the .kicad_mod file by hand? Committed yesterday; now the text module dialog contains the layer combo like for graphics item. Like graphic items, starts by default on silk, after that you can change the layer. This is for both reference/value and user text, so you can add module text to comments or whatever. Heavy testing is of course appreciated :D -- Lorenzo Marcantonio Logos Srl Thanks for taking on this work Lorenzo - looks like it's underway nicely. Thank-you Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rename proposal
On 10 September 2014 07:49, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: While inspecting for text module usage, I found a couple of call which (for a little) puzzled me :D IgnoreMTextsOnCopper and IgnoreMTextsOnCmp in the collector 'guide' class. At first I tought the first was referring to actual copper layers :P Then I realized they referred to board sides... wouldn't they better be called IgnoreMTextsOnFront and IgnoreMTextsOnBack ? Also what is their supposed semantic? At the moment since text on modules is only on SilkTop the collector simply checks for the module side. But the idea is that modules could have text on other layers too, possibly on the other side. Is that predicate meant only to act on silk text or on other text too? Just a design decision. In the meantime I'll add them to the list of things to inspect to gleam the *actual* usage. Of course the same proposal holds for IgnoreModulesOnCu and IgnoreModulesOnCmp (given how many board are dual populated it's difficult to tell the copper side from the component side...) Hi Lorenzo, I think the rename should be done, but I think we should probably end up with: IgnoreMTextsOnF_Cu IgnoreMTextsOnB_Cu because the constants F_Cu and B_Cu are compared when looking for the layer generally in the same test. For example in collectors.cpp:296 and collectors.cpp:299: if( m_Guide-IgnoreMTextsOnCopper() module-GetLayer()==B_Cu ) if( m_Guide-IgnoreMTextsOnCmp() module-GetLayer()==F_Cu ) Secondly, I think the above tests in the collector should remain true. If the PCB item is text and it belongs to a module that is placed on the F_Cu layer we should ignore it if the IgnoreMTextsOnCmp() function returns true. More fancy filtering needs a more advanced UI which can filter based on more information from the user which can control the collector more precisely. These functions are actually only used when collecting (enumerating) pads anyway and is used to disregard all module text items. So the functionality will break that tool if we change it's meaning to not ignore all module texts. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rename proposal
On 10 September 2014 14:56, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Wed, Sep 10, 2014 at 02:20:48PM +0100, Brian Sidebotham wrote: I think the rename should be done, but I think we should probably end up with: IgnoreMTextsOnF_Cu IgnoreMTextsOnB_Cu because the constants F_Cu and B_Cu are compared when looking for the layer generally in the same test. For example in collectors.cpp:296 and collectors.cpp:299: BE CAREFUL. On module objects the layer can only be F_Cu and B_Cu, indicating that the module is mounted on the front or the back side. It doesn't mean Module texts on Front Copper, it means Texts on modules mountend on the front side. It's a silly overload of the layer slot, but it's historic now :D in reality the module IS-NOT-A BOARD_ITEM in the strict sense (since it's more like a container), but that's how it's modelled at the moment. Yep, I understood all that before I proposed the names. the F_Cu layer we should ignore it if the IgnoreMTextsOnCmp() function returns true. My opinion is the same. The condition would change from module-GetLayer()==B_Cu to IsBackLayer(textitem-GetLayer()) or something similar (to handle modules with text on their back). However I'll need to inspect actual usage of these predicate to verify that's the intended behaviour. Hopefully here you mean IsBackLayer(module-GetLayer()) otherwise you're breaking stuff. I don't really have an opinion about the test for the front or back layer. I don't see any ambiguity in the == F_Cu or == B_Cu test against the module's layer. The collector must exclude ALL text in a module (forget about what layer that text is on) when IgnoreMTextsOnCopper() returns true. If you are getting confused between text layers and module layers then you can further play around with the function name to something like IgnoreTextInModulesOnF_Cu() IgnoreTextInModulesOnB_Cu() Which more accurately describes their meaning. But then I thought the previous effort was pretty obvious too. :P Along with this, we can also expand the doxygen text for these functions to describe their meaning more verbosely such that we're all aware of their intention. These functions are actually only used when collecting (enumerating) pads anyway and is used to disregard all module text items. So the functionality will break that tool if we change it's meaning to not ignore all module texts. It used only for that? Easy to check then :D Yep, or at least that's what grep says! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rename proposal
On 10 September 2014 16:14, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Wed, Sep 10, 2014 at 03:57:51PM +0100, Brian Sidebotham wrote: Yep, I understood all that before I proposed the names. Then why not IgnoreMTextsOnFront and IgnoreMTextsOnBack ? Cu has no relationship with the meaning for the modules, it's only a coding artifact/convention. The world survives on convention. If that is ours, why invent new? Hopefully here you mean IsBackLayer(module-GetLayer()) otherwise you're breaking stuff. I don't really have an opinion about the test for the front or back layer. I don't see any ambiguity in the == F_Cu or == B_Cu test against the module's layer. No, that was intended. The problem is this: first of all IsBackLayer (or IsFrontLayer) on the module layer is wasted since that can only be F_Cu or B_Cu; the semantic I asked before is, what of the following ones is the intended behaviour: a) text on a module, where the module is placed on the front/back side (current behaviour) this one. I mentioned that in each of my mails I think. (b) breaks the ONLY current use of these settings as far as a quick grep suggested anyway. or b) text on a module, where the text is on a layer in the front/back side (since a module front mounted can be usefully have text on the back; example: a reverse mount trimmer) In other words: in the proposed names IgnoreMTextsOnFront and IgnoreMTextsOnBack the 'OnFront' and 'OnBack' part refers to the module (now) or the text (possibly)? Both of these could have their use, of course. The collector must exclude ALL text in a module (forget about what layer that text is on) when IgnoreMTextsOnCopper() returns true. Need to look yet at this OnCopper predicate If you are getting confused between text layers and module layers then you can further play around with the function name to something like IgnoreTextInModulesOnF_Cu() IgnoreTextInModulesOnB_Cu() IgnoreTextInModulesOnFront and IgnoreTextInModulesOnBack accurately describe the current behaviour (as I said the Cu part makes no sense). IgnoreFrontTextInModules and IgnoreBackTextInModules describes the other behaviour. Yep, or at least that's what grep says! Then I'll look at it and decide the best name :P Good, I think we're going round in circles on a very simple couple of functions with clearly defined use. :) Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rename proposal
On 10 September 2014 16:54, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Wed, Sep 10, 2014 at 04:49:55PM +0100, Brian Sidebotham wrote: The world survives on convention. If that is ours, why invent new? Because *our* convention is Front/Back. The collector itself uses it for pads, for example. Good, I think we're going round in circles on a very simple couple of functions with clearly defined use. :) Found the determining function with explains the intended behaviour: the collector constructor itself uses the show front text/show back text visibles to initialize them. So the meaning is text placed on a front layer, not text in a module placed on the front side. I don't get that conclusion considering that module text placed on a front layer is currently impossible as instead in a module it will be placed on F_Silk!! No risk of breaking anything since, as you said, they are set in pair in the only non-default setting. -- Lorenzo Marcantonio Logos Srl I disagree, but no matter. If you make the changes to those functions to change their behaviour to exclude just module text that is on F_Cu or B_Cu then you'll also need new functions to exclude all module text regardless of layer based on the module being on either the Front or Back of the board and fix MODULE_TOOLS::EnumeratePads. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rename proposal
On 10 September 2014 17:31, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Wed, Sep 10, 2014 at 05:14:43PM +0100, Brian Sidebotham wrote: I don't get that conclusion considering that module text placed on a front layer is currently impossible as instead in a module it will be placed on F_Silk!! Because at the moment there is *no* way to specify another layer for the text. Text on a module is *always* on F_SilkS and could be flipped with the module to B_SilkS. No other layer is possible. *Definitely* text can't go on F_Cu or B_Cu and probably never will for DRC issues. Only the module itself can be on F_Cu or B_Cu (and *only* on one of these two). If you make the changes to those functions to change their behaviour to exclude just module text that is on F_Cu or B_Cu then you'll also need new functions to exclude all module text regardless of layer based on the module being on either the Front or Back of the board and fix MODULE_TOOLS::EnumeratePads. From comments in the headers and constructors the intended behaviour is exclude text in front/back sides. So if I set IgnoreTextMFront it would ignore: - For a module placed on the front (F_Cu on the module) Text on F_SilkS (that's the *only* case possible now) and then F_Fab, F_Adhes, F_Whatever; but, also: - For a module placed on the back: B_SilkS, B_Fab, B_Adhes, B_Whatever since if a module is flipper, back text on the modules actually appears on the front! Currently this situation can't happen but it will in a short time and that's the reason for which you need to check the text layer, not the module one. As for the pad collector, it sets both so in fact it will ignore text on *any* layer (independently from the layer the module is on). So compatibility is assured. -- Lorenzo Marcantonio Logos Srl Fair enough, I disagree and this just over-complicates things needlessly in my opinion. You'll have to track all of the layers that we're going to allow text to appear on in a module and limit the layer selector to that range and duplicate that in all the functions that have to deal with this - it's just more assumptions that end in disaster or limited functionality in the end. My opinion - just allow module text on any layer. Give the module designer flexibility. That way we don't need more special cases, and functions do what they say on the tin without needing IgnoreModuleTextsOnFrontIfOnSilkOrFabOrAdhesOrWhatever() But as you're in front of the keyboard, good luck! :D Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 5123: Implemented special rules for plotting assembly layers
On 9 September 2014 04:56, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Mon, Sep 08, 2014 at 10:27:45PM +0100, Brian Sidebotham wrote: Sorry, but I don't like this patch because I want control of where the reference text goes on both assembly and silk layers. It doesn't necessary want to go in the centre of an electrolytic cap for example. Only for the very basic components is the centre an okay choice. I would rather just allow to have a reference object on the assembly layer as well as the silk layer. I implemented the IPC rule which tell that's the reference on assembly goes to the insertion point (for pick and place cross-check). I think it's OK if someone doesn't like it :D In fact it's silly for THT component were the insertion point often is on pin 1. However at the moment the reference simply *doesn't* appear on assembly so it doesn't actually breaks the plot IMHO; at least at the moment is useful. Hi Lorenzo, Sorry for the late reply. I understand what you're saying about there currently being nothing of the reference on the assembly layer. However, essentially bodging something on now just creates an obstacle for someone later on down the line who wants to implement this more thoroughly. I think as with the silk screen version of the reference, we should add the same to the assembly layer. However, I'd much rather see us use text substitution for things like this. I realise that's a more involved task - but it's even more involved if first we have to try and support old behaviour that's essentially been hard-coded into the plotter. If I don't see it on screen, I don't want it suddenly appearing in a plot silently. If you want IPC compatible modules, then I guess you need to add the reference designator text to the module at the insertion point. I agree with you that a separate designator would be useful. The whole story is here http://blogs.mentor.com/tom-hausherr/blog/tag/reference-designator/ In short, silk refdes must be always outside the part, assembly refdes needs to be always inside the part; quite a conflicting requirement... since on silk you need to always hand place it (if it fits on the board, i.e. never in my case:D) and many CAD have no separate assembly origin it get placed on the insertion point (if you can't move it as you reasonably asked). The big problem is that reference and value are two slots in the module class, not entities in the module and are treated in a special way (in eeschema instead they are simply the 'first' in the attribute list). And that text (other than in the file format) isn't really handled in layers other than silk (could work but probably something would glitch). In fact, if you noticed it, they are not even controlled by layer but from the 'visibles' palette (and have their own colors). How to handle that? The obvious thing would to have a separate AssemblyRef member. And duplicate the whole shebang for handling the current reference field *all over* pcbnew, adding a keyword in the file format and so on. Well, it smells to me:P what if you also want value on assembly? :D Obvious I don't think is generally good. Just making another special-case item is like replaying the old broken record. There's nothing really special about some text on a layer, and just because it's a reference designator shouldn't mean it's special either. Also how to handle it in the UI? do we allocate another visible index? Even the picking code would need to be duplicated... I don't think we want yet another tickbox, or another special item to worry about - it's just dynamic text. Suggestion on how to handle it are well accepted. I was thinking maybe in some kind of printf-like expansion in user text where you could place %R or %V or something and put it on whatever layer you wanted to achieve the effect. The %-thing would be easy, checking that text works on different layers is not :D for assembly we could just put a rule that use a default if no other text is specified on the layer... Variable substitution in text on any layer would be my preferred way of achieving this. So a first step (useful in any case) would be changing text-in-module entity specifications from: - Reference lives on SilkTop (and it's controlled by a own 'visible') - Value lives on SilkTop (and it's controlled by it's own 'visible') - User text lives on SilkTop (and it's controlled by the master 'show text' visible) ...to: - Reference and Value *no change* (seems fine to me) - User text on any layer allowed in the module (i.e. the usual restrictions which change from one day to another); I think it could be controlled by the same master visible but taking the layer color. That would be useful for having comment text in the module (I've missed the feature in the past, actually...). Probably the new module editor can handle the layer change, I didn't check. Otherwise I think that simply adding the usual layer
Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 5123: Implemented special rules for plotting assembly layers
Sorry, but I don't like this patch because I want control of where the reference text goes on both assembly and silk layers. It doesn't necessary want to go in the centre of an electrolytic cap for example. Only for the very basic components is the centre an okay choice. I would rather just allow to have a reference object on the assembly layer as well as the silk layer. Best Regards, Brian. On 8 September 2014 19:00, nore...@launchpad.net wrote: revno: 5123 committer: Lorenzo Marcantonio l.marcanto...@logossrl.com branch nick: kicad timestamp: Mon 2014-09-08 19:57:39 +0200 message: Implemented special rules for plotting assembly layers - Reference is visible on silk and the corresponding assembly layer - Reference is shown on assembly always on the component insertion point Hidden references are not forced shown in assembly plots (there is already a user option for that) modified: pcbnew/plot_brditems_plotter.cpp -- lp:kicad https://code.launchpad.net/~kicad-product-committers/kicad/product You are subscribed to branch lp:kicad. To unsubscribe from this branch go to https://code.launchpad.net/~kicad-product-committers/kicad/product/+edit-subscription === modified file 'pcbnew/plot_brditems_plotter.cpp' --- pcbnew/plot_brditems_plotter.cpp2014-08-24 07:05:07 + +++ pcbnew/plot_brditems_plotter.cpp2014-09-08 17:57:39 + @@ -124,6 +124,13 @@ if( textLayer LAYER_ID_COUNT )// how will this ever be true? return false; +// Special rule: assembly always shows reference from the silk layer +if( (m_layerMask[F_Fab]) (textLayer == F_SilkS) ) +trace_ref = true; + +if( (m_layerMask[B_Fab]) (textLayer == B_SilkS) ) +trace_ref = true; + if( !m_layerMask[textLayer] ) trace_val = false; @@ -216,7 +223,12 @@ // calculate some text parameters : size = pt_texte-GetSize(); -pos = pt_texte-GetTextPosition(); + +// Assembly drawings always have the reference on the origin +if( m_layerMask[F_Fab] || m_layerMask[B_Fab] ) +pos = static_castMODULE*( pt_texte-GetParent() )-GetPosition(); +else +pos = pt_texte-GetTextPosition(); orient = pt_texte-GetDrawRotation(); ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxWidgets version.
KiCad-Winbuilder is using a patched 3.0.0 so it's pretty stable at the moment. I wanted to wait for a period of no bug reporting against wxWidgets (with regards to KiCad) until I bumped the version in the wxWidgets-cmake project that Winbuilder uses. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Configuration file relocation.
Moses, Thanks for doing this work - config files instead of the registry settings on Windows has been on my list forever and I never got round to doing anything about it. So thanks for getting on and doing it as well as tidying up the Linux files. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Edge.Cuts layer in the module editor
On 4 September 2014 10:03, Maciej Sumiński maciej.sumin...@cern.ch wrote: On 09/03/2014 10:36 PM, Wayne Stambaugh wrote: On 9/3/2014 12:33 PM, Brian Sidebotham wrote: I think we could do it in a similar fashion to EESCHEMA (it's a more pleasant experience when things work in a similar way) Any vertexes on the Edge.Cuts layer that do not match *exactly* should be highlighted with a square centred on the disconnected vertex(es). Secondly, we can apply similar logic to pads being magnetic to tracks by having Edge.Cuts vertexes being able to snap to currently off-grid Edge.Cuts vertexes as well as to the grid. This way anyone can guarantee they have at least connected all of their Edge.Cuts drawings. Secondly, part of the DRC check can also list disconnected Edge.Cuts vertexes - because that should at least be a warning, if not an error. I don't think there's any reason to have disconnected vertexes on the Edge.Cuts layer is there? Perhaps for drawing a rout line, but then I draw a rectangle with the correct width of the router bit I want used so it is less ambiguous. Best Regards, Brian. All that sounds good, but demands more work than I initially expected, so it may take time. Recently the time that I can devote to KiCad development is a bit constrained. The PNS router uses its internal model to implement snapping, therefore I wonder if it would not be better to delay snapping until the current model is upgraded. The rest of proposed changes should be possible to implement without any other dependencies. Excellent suggestions. This seems like a reasonable path forward. I really like the snapping idea as an easy way to close the vertices. I always have to manually go back and use the segment properties to make sure each vertex ends at the same point if I don't get them right the first time. Should I add this to the road map? It seems like a good candidate. Good ideas are worth noting and putting to the plan. That way they will not be forgotten. Hi Guys, Please put it on the road map and assign my name next to it and I'll get it done. I don't meant to pile stuff onto other people's plates, but I think this is the most intuitive way of working when lines must be continuously connected. Personally I do not want KiCad inserting segments and attempting to auto-close anything for me. If we need to change the data model to expose snap objects then let's also get that on the road map, or is that already there? I probably can't take on that sort of work in spare time in the evenings. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Edge.Cuts layer in the module editor
On 3 September 2014 17:03, Maciej Sumiński maciej.sumin...@cern.ch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Sep 03, 2014 at 10:22:03AM +0200, Maciej Sumiński wrote: Healing could be done another way. Instead of moving vertices, it could be better to add the missing segments. If they are no longer than a line thickness, then it is not noticeable to bare eye and should fix the manufacturing problem. User should be notified of such changes, so he could verify them. Jean-Pierre, What do you think about it? Maybe it is better to connect edges if there is a break smaller than the thickness of segments instead of simply accepting them as they are? Regards, Orson I think we could do it in a similar fashion to EESCHEMA (it's a more pleasant experience when things work in a similar way) Any vertexes on the Edge.Cuts layer that do not match *exactly* should be highlighted with a square centred on the disconnected vertex(es). Secondly, we can apply similar logic to pads being magnetic to tracks by having Edge.Cuts vertexes being able to snap to currently off-grid Edge.Cuts vertexes as well as to the grid. This way anyone can guarantee they have at least connected all of their Edge.Cuts drawings. Secondly, part of the DRC check can also list disconnected Edge.Cuts vertexes - because that should at least be a warning, if not an error. I don't think there's any reason to have disconnected vertexes on the Edge.Cuts layer is there? Perhaps for drawing a rout line, but then I draw a rectangle with the correct width of the router bit I want used so it is less ambiguous. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] version info does not get updated
On 3 September 2014 20:04, yann jautard brico...@free.fr wrote: Le 03/09/2014 20:08, Wayne Stambaugh a écrit : On 9/3/2014 8:08 AM, yann jautard wrote: Le 03/09/2014 12:32, yann jautard a écrit : Le 02/09/2014 18:24, Wayne Stambaugh a écrit : I have this on my list of things to look at. It should be possible to get CMake to generate make files that compare the source repo version against the version.h file and recreate it as required every time make is run. Currently, the only time version.h gets updated is when the CMake files are modified or make rebuild_cache is run. I checked it right now : I added make rebuild-dep to beginning of the build process in kicad-install.sh. Running it with a kicad install witj not up to date version info results in rebuilding only build_version.cpp and relinking all parts that have a user interface. Rebuilding the dependencies is not what you want to do if all you are trying to do is update the version string. (...) yes of course that was rebuild_cache, I made a mistake writing the mail. So as you said you want to get Cmake to compare the version with the one in the file, I'm pretty sure it is not necessary. Just calling make rebuild_cache before make do the job pretty well. I think the kicad-install.sh script could be updated to add this make rebuild_cache step before compilation. That way you will be sure version is updated each time, and bug reports by guys like me will be accurate. This is where the problem lies if you install with this script and it doesn't rebuild_cache on an existing source tree. Winbuilder does this at the start of each run to keep the version information up-to-date. IMO the versioning we're using is fine just the way it is. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Project proposal
On 1 September 2014 10:17, Javier Serrano javier.serrano.par...@gmail.com wrote: On Sat, Aug 30, 2014 at 8:47 PM, Wayne Stambaugh stambau...@verizon.net wrote: [snip] I am proposing that we move to a model more like the Linux kernel where there is a merge window for new features followed by a stabilization period. [snip] This looks like a very good plan to me. You can count on our help. 3) Documentation [snip] There has been a suggestion of moving our documentation to a text base layout format to make it more version control and translation friendly. I'm all for that. How is the current documentation effort being handled? Is there a separate mailing list for it? I don't recall seeing much documentation discussion here. What do the main people involved think about changing to a markup text-based format? Cheers, Javier Oh, that quickly reminds me - I had started looking at this here: https://github.com/BrianSidebotham/KiCAD-Docs-mmd I think the problem we need to get around if Markdown is chosen as the markup because of it's simplicity that formatting the size of images is not really present, and this is why it's hard to get a formatted PDF document out correctly. However, we all have browsers these days, perhaps the documentation in html rather than PDF makes more sense anyway. For HTML of course, we can use CSS to style the output - there's no CSS in the above html output. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] kicad-pcb.org
On 31 August 2014 23:49, Aaron Pelly ape...@monkeymasters.co.nz wrote: On 01/09/14 02:08, Maciej Sumiński wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/31/2014 12:13 AM, Cirilo Bernardo wrote: [snip] Is there anyone on the list with web page skills? Sounds like a good opportunity to ask people on the users mailing list too. KiCad would not suffer from a few extra contributors. Regards, Orson Hi guys, I've been lurking in here for a few months, with nothing of value to contribute. Perhaps I can lend a hand here? I'm no expert, but I'm capable, and more than happy to spend some hours working on whatever you think is appropriate. English is my first language and I'm reasonably articulate. Perhaps Wayne could suggest something small for me to have a crack at; then you can judge by the result? I'm following the conversation either way. Aaron. Hi Aaron, Thanks for your offer, please email Miguel and request a login for www.kicad-pcb.org so that you can start contributing. His email address (from his last mails) is mangel...@redhat.com Thank-you! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Project proposal
On 1 September 2014 20:17, Martijn Kuipers martijn.kuip...@gmail.com wrote: On 01 Sep 2014, at 19:54, jp charras jp.char...@wanadoo.fr wrote: Le 01/09/2014 11:44, Brian Sidebotham a écrit : On 1 September 2014 10:17, Javier Serrano javier.serrano.par...@gmail.com wrote: On Sat, Aug 30, 2014 at 8:47 PM, Wayne Stambaugh stambau...@verizon.net wrote: [snip] I am proposing that we move to a model more like the Linux kernel where there is a merge window for new features followed by a stabilization period. [snip] This looks like a very good plan to me. You can count on our help. 3) Documentation [snip] There has been a suggestion of moving our documentation to a text base layout format to make it more version control and translation friendly. I'm all for that. How is the current documentation effort being handled? Is there a separate mailing list for it? I don't recall seeing much documentation discussion here. What do the main people involved think about changing to a markup text-based format? Cheers, Javier Oh, that quickly reminds me - I had started looking at this here: https://github.com/BrianSidebotham/KiCAD-Docs-mmd I think the problem we need to get around if Markdown is chosen as the markup because of it's simplicity that formatting the size of images is not really present, and this is why it's hard to get a formatted PDF document out correctly. However, we all have browsers these days, perhaps the documentation in html rather than PDF makes more sense anyway. For HTML of course, we can use CSS to style the output - there's no CSS in the above html output. Best Regards, Brian. After a lot of try (using Markdown, LibreOffice .fodt files and trying to use some other formats), I agree with Brian: Using html format for *current Kicad documentation* is the best way: * Current doc is very easy to convert to html format (LibreOffice, at least the latest version 4.3.1, works fine when switching to html file format) from the current .odt format ( we have more than 1000 pages of currently actively maintained doc, therefore this is a very important thing). * No need to still generate the .pdf files, html files are enough. * Using html files instead of .odf files, and do not use anymore pdf files fixes our major issue: binary files are not easily handled by launchpad versioning system). * Kicad doc file can be converted to html files with very few changes in code (FYI, in early times of Kicad, the html format was used) I find it much easier to move pdf-files around then html-files. Why not use a solution such as latex, or perhaps less academic, sphinx ? The cakePHP book is done with sphinx, which is basically restructured text (so you can keep it in a CVS), but can output a myriad of formats, such as html, pdf (via latex), ePub, There is a tool to convert from odf, but I have not tried it. For those interested, more info on sphinx can be found here: http://sphinx-doc.org/intro.html Warm regards, Martijn I'm unsure why the files need moving around? Almost the entire weight of this decision should be in the hands of the people who write the documentation. Latex I'm sure is definitely out - it's hard to see the content for the formatting, so it's not easy to work with. We want to create a situation where documentation writers can use text diffs to update their language's documentation. So something like restructured text may work well because it has some image formatting capabilities. Plain HTML can actually do the job too, although most people use a language that compiles to html to make the formatting even cleaner. Markdown has books written in it too. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] kicad-pcb.org
On 30 August 2014 23:13, Cirilo Bernardo cirilo_berna...@yahoo.com wrote: - Original Message - From: Brian Sidebotham brian.sidebot...@gmail.com To: Wayne Stambaugh stambau...@verizon.net Cc: KiCad Developers kicad-developers@lists.launchpad.net Sent: Saturday, August 30, 2014 9:19 PM Subject: Re: [Kicad-developers] kicad-pcb.org Looks like it just fell over, however I updated http://www.kicad-pcb.org/display/KICAD/About+KiCad last night with the information in AUTHORS.txt There's some more to do, but at least the majority of it is up there. I'd like to do some info on the individual programs under About KiCad. I believe Miguel is the guy to speak to. Best Regards, Brian. On 30 August 2014 01:09, Wayne Stambaugh stambau...@verizon.net wrote: Now that I am the project leader, it would be useful for me to know who the kicad-pcb.org site maintainer is and who has write access so I can enlist (read arm twisting ;)) help getting changes made and keeping things up to date. Thanks, Wayne Is there anyone on the list with web page skills? The 'about kicad' page needs some work so it's a more professional read. Not much is said of SoftPLC for example (from what's there I have no idea who they are) and the wording is awkward. This is what I wrote about SoftPLC's involvement in KiCad essentially as a placeholder; It's up to Dick what goes in this section and I contacted him directly to read and send me any amendments he would like to make. So we don't need anyone else, because Dick is the one who can complete this section the best. Jean-Pierre has cleared up and amended his sponsor section for me. It would also be good to get permission to use logos from the corporate supporters to put up on the 'about' page as well as the main page; we have to be careful about the use of logos and make sure we have appropriate permission to use them where we do. Perhaps the logo negotiations can extend to use in the preface of the documentation as well. Other companies may be more comfortable with testing KiCad for their use if they know that other companies use it successfully and contribute to its development. It sounds like Wayne is keen to do a more complete page on Corporate sponsor page on the site. In my opinion logos should be left out - they are only something that will bit rot as companies change their logos; It's easier to just link to the corporate website and then there's nothing we need to maintain. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] version info does not get updated
The version is essentially created during the CMake configure step - when CMake generates its cache of variables. You need to re-create this cache to update the value: make rebuild_cache That should update to the same as bzr revno. Best Regards, Brian. On 31 August 2014 21:47, Andrew Zonenberg azonenb...@drawersteak.com wrote: I've observed the same issue with my builds. The only workaround I've found to date is to delete the build directory and do a full rebuild. On Sun, 2014-08-31 at 20:56 +0200, Nick Østergaard wrote: Hi Yann Does 'bzr revno --tree' result in the same? 2014-08-31 20:21 GMT+02:00 yann jautard brico...@free.fr: REVISION is set to TESTING, I use the script daily, it's the first time I notice something like that. the result of bzr log in my kicad source tree starts by : revno: 5106 fixes bug: https://launchpad.net/bugs/1035151 committer: Wayne Stambaugh stambau...@verizon.net branch nick: kicad timestamp: Fri 2014-08-29 16:23:40 -0400 so it updated the source correctly. And considering the number of files that has be recompiled, it updated something in the bin files. Le 31/08/2014 19:38, Nick Østergaard a écrit : That just looks like it did not update. What is the REVISION variable set to in the sript? It should be $TESTING, where that is last:1. 2014-08-31 18:12 GMT+02:00 yann jautard brico...@free.fr: Hi all, I don't know if this is important, but I just updated my kicad install this afternoon, and I noticed the kicad version information is not up to date : yann@yann-netbook:~/kicad_sources$ ./kicad-install.sh --install-or-update (...) step 3) checking out the source code from launchpad repo... Tree is up to date at revision *5106* of branch http://bazaar.launchpad.net/~kicad-product-committers/kicad/product local source working tree updated. (...) All KiCad --install-or-update steps completed, you are up to date. and then, the kicad windows says this : Application: kicad Version: (*2014-08-26 BZR 5099*)-product Release build wxWidgets: Version 3.0.0 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.8.2,wx containers,compatible with 2.8) Platform: Linux 3.13.0-35-generic i686, 32 bit, Little endian, wxGTK Boost version: 1.54.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=OFF KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON you can see the compilation date is wrong (we are the 14 08 31) and the version number is wrong. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Andrew Zonenberg PhD student, security group Computer Science Department Rensselaer Polytechnic Institute http://colossus.cs.rpi.edu/~azonenberg/ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] version info does not get updated
On 31 August 2014 22:27, Andrew Zonenberg azonenb...@drawersteak.com wrote: Why does CMake not recompute this particular value during the pre-compile configuration step? It runs checks for changed stuff every time you make anyway and only caches certain things. Is it really that hard to not cache this particular value? Currently KiCad uses a configure file mechanism for the version.h file and it's not normal to regenerate these each time you make otherwise you end up re-compiling everything that uses the file and then re-linking everything that links to that target if the target's a library (which in this case it is). Therefore, when you bzr up - make rebuild_cache too in order to update the version number. Caching this value makes subsequent repetitive builds quicker. If you can suffer the time, just do a simple cheat: bk.sh #!/bin/bash make rebuild_cache make just use bk.sh instead of make... The following is from CMakeModules/version.h.cmake : /* * Define the current source code Subversion commit number. The version * string defined below does not update automatically when building the * source with make. Run make rebuild_cache to update version strings. */ Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] version info does not get updated
On 31 August 2014 22:52, Andrew Zonenberg azonenb...@drawersteak.com wrote: What I did in my previous build systems is to regenerate the file in a temporary directory then check if the files had the same hash. If they didn't I'd update the file. This way, if you don't change the file's contents it doesn't get touched and nothign else gets rebuilt. Yeah, everything's possible, but when you're doing local commits you're still going to get needless compilation and relinking because the bzr rev number has changed. Generally the bzr revno is a bit of a pain for developers if you commit often but useful for everyone else. I guess someone could improve the situation if they had the time, but re-compilation and re-linking everytime would be a bit of a step backwards. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] kicad-pcb.org
Looks like it just fell over, however I updated http://www.kicad-pcb.org/display/KICAD/About+KiCad last night with the information in AUTHORS.txt There's some more to do, but at least the majority of it is up there. I'd like to do some info on the individual programs under About KiCad. I believe Miguel is the guy to speak to. Best Regards, Brian. On 30 August 2014 01:09, Wayne Stambaugh stambau...@verizon.net wrote: Now that I am the project leader, it would be useful for me to know who the kicad-pcb.org site maintainer is and who has write access so I can enlist (read arm twisting ;)) help getting changes made and keeping things up to date. Thanks, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] New Project Leader
On 22 August 2014 17:41, Dick Hollenbeck d...@softplc.com wrote: Ladies and Gentlemen: With great respect and humility I am turning over KiCad project leadership to Mr. Wayne Stambaugh. Wayne has established himself as a seasoned leader and software architect. His software architectural skills and leadership skills make him in my opinion the best of available persons to fill this role. We should hope and wish that he finds the job rewarding and fulfilling in a way that leads to an extended term in this volunteer position. I obviously have confidence in his abilities, but I don't over estimate his staying power, nor should you. Please be kind and respectful to him. It is time for me to move out of the top spot and off the mailing list. I want to acknowledge Brian Sidebotham with special thanks for his faith in my leadership and his exceptional contributions in the realm of KiCad Winbuilder. It was his faith in my vision that motivated him to do an unspeakable volunteer effort from which hundreds of KiCad users benefit. While I thank him for his confidence in that vision of mine, you all should thank him for his actual time and leadership in making KiCad on Windows worth using. His efforts in promoting CMake as a build engine warrant industry and world-wide acclaim and he is due a bonus from Kitware. I want to acknowledge and thank Fabrizio Tappero, who's graphics/icons, and user manual efforts should go down as some of the most important contributions in KiCad's history. I want to acknowledge and thank Carl Poirier who is overseeing what is quickly becoming a world-wide resource. At my egging, he stepped up and is now overseeing what is becoming something truly exceptional along with the efforts of generous contributors. I wish him the best, I encourage him to be a leader and encourager among reluctant volunteers. I am proud to have been an inspiration in something that he can proudly put on his resume some day. I want to thank Javier Serano, whose confidence in our project direction and leadership inspired him to join and bring in some additional world class talent and team players, Tom and Orson, as well as KiCad team leadership and seasoned experience. Lastly I want to thank Jean-Pierre for his friendship, for his faith and confidence in my sometimes loud and brash leadership. But were it not for his stabilizing influence in all things KiCad, we'd all be making less PCB boards, or doing them more expensively. Please take care of my good friend Wayne Stambaugh. I have prayed with Wayne, I know his son. You could not have a better man at the helm. Appreciation goes a long way towards keeping this project healthy, and for it to be healthy you need a class act at the top, you have one in Wayne. Dick P.S. *) The project has SoftPLC Corporation's permission to re-license its copyrights under GPL3. *) When somebody other than superman Jean-Pierre surpasses this number of commits: $ bzr log | grep 'dickelbeck\|Hollenbeck' | wc -l send me a personal note and I'll send him a congratulatory memo. :) *) It would be nice if the kicad-pcb.org website listed SoftPLC Corporation as a historically significant corporate sponsor. Out. Hi Dick, Sorry for the late reply! I'm so sorry to see your time with KiCad come to an end - you've done great things with it and should feel extremely proud; As should SoftPLC as a corporate sponsor. I will be sure to update http://www.kicad-pcb.org/display/KICAD/About+KiCad to include all of the lead developers actually and add the SoftPLC corporate sponsor for you - it's more than well deserved! Jean-Pierre's university should be on there too. Clearly without your dedication and prolific commits we would be nowhere near where we are now. Thank-you so much for your continued effort throughout the years! You'll be sorely missed. I only wish I could have met you in Grenoble. Good Luck with whatever you find yourself doing next, and I really hope you find both the satisfaction and gratitude you deserve from it. Thank-you for your kind words, they're humbling. I'm eternally grateful, and thank-you for your dedicated work on KiCad, Python-a-mingw-us and all of the support you gave in getting KiCad to where it is today, it's a stunning achievement. Wayne, Congratulations and well done - I'm sure everyone feels a steady hand at the tiller. I think all the developers know the extensive work you've also been doing in re-factoring and untangling the codebase over the years and all developers will be extremely thankful of that! Please know that I'm here to help (as and when our baby allows at the moment anyway!). My current work is just keeping Winbuilder ticking over, and also implementing a more advanced Template Field Names editor in the EESCHEMA options dialog - which is taking ages, but should be ready soon. Best Regards, Brian
Re: [Kicad-developers] eeschema modular kicad work
On 20 August 2014 13:44, yann jautard brico...@free.fr wrote:
just FYI, 5084 does not compile any more.
/home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:
In member function ‘virtual void
DIALOG_MODULE_BOARD_EDITOR::OnCancelClick(wxCommandEvent)’:
/home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:185:1:
error: expected primary-expression before ‘’ token
TREE
^
/home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:185:3:
error: expected primary-expression before ‘’ token
TREE
^
and at least 50 more lines similar to this one.
looking at the problematic file, found some pretty strange syntax wich I
guess it is not c++ :
void DIALOG_MODULE_BOARD_EDITOR::OnCancelClick( wxCommandEvent event )
{
TREE
EndQuasiModal( -1 );
===
ENDQUASIMODAL( -1 );
MERGE-SOURCE
}
looks like some patching as not finished properly or something similar.
Hi Yann,
There's nothing wrong with the source, see:
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp
You have a locally unresolved conflict because you've had some local
changes that BZR cannot resolve without your help. See
http://doc.bazaar.canonical.com/beta/en/user-guide/resolving_conflicts.html
You can check the status to see the unresolved conflicts by using the
bzr status command.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] eeschema modular kicad work
Hi guys, Sorry for asking dumb questions, but what is this whole QuasiModal stuff for? Tom Hi Tom, No question is dumb. See Yann's description (from earlier in this thread) of the problem below, to which Quaimodal is a good solution. Best Regards, Brian. --- Hi Dick, and all the others involved in the modular design. I noticed something regarding the modular kicad apps : When you have some modal window opened in one of the app, eg the module properties window in pcbnew, all the kicad modules are frozen until you close that window. It's not a big deal, but rather boring, when you need to check something in eeschema when editing module properties, you can't launch eeschema with the button in the kicad main window as it is not responding. And if eeschema was alredy opened you can't even scroll the schematic. I don't know if it is technically possible to change this behaviour, but I think it could be a great improvement. Just my two cents. regards, yann ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad build.
On 16 August 2014 17:44, Wayne Stambaugh stambau...@verizon.net wrote: One of the tasks that I have committed to working on in the KiCad road map is to clean up the current mess we have created by allowing dependency libraries to be built as part of the KiCad source build. The only exception I see for the time being is Boost. Although I am have my reservations on that as well. Why you ask? I've spent several days trying to get KiCad to build on Windows using MSYS2 as my build environment and mingw64 as my target environment. Every single library dependency with the exception of our custom Boost and avhttp (which could easily be build and installed using CMake) are already packaged for me. However, the current KiCad build insists on downloading and building some libraries from source that are already installed. This is silly. I can resolve the issues by passing all of the PACKAGE_ROOT_PATHs when I run CMake but that is silly as well since my build environment already points the correct path. Originally I intended to create a separate project to build the KiCad library dependencies but I have since changed my mind. I do *not* think it is asking too much of developers to learn how to build and/or install libraries on their preferred platform. If as a developer you must have this done for you automatically, I am going to please ask that *you* create a separate platform specific build tool such as the excellent kicad-winbuilder that Brian has created. This will significantly simplify the KiCad CMake files and eliminate the situation I described above. My preference and goal is that the KiCad CMake files be used to build KiCad, not library dependencies. Initially, I plan to remove the dependencies that do not require any patching to build which currently are avhttp, swig, cairo, libpng, pixman, pcre, pkgconfig, and glew. Then I will remove the dependencies with platform specific patches which are openssl, wxwidgets and wxpython. Then I will try to figure out what to do with the problem child that is Boost. I would also suggest that all platform specific library dependency build patches be remove as well leaving only the Boost patches that are required for all platforms (except the context switching patches). My goal here is not to step on anyone's toes it is to get our build system under control so that I can build *KiCad* rather than figure out how to get the dependencies to build or not as the platform dictates. I expect our code to be well designed and I don't think expecting the same from our build system design is out of line. If any one has major objections then we will have to figure something out because I am not going to continue to spend valuable time fighting our build tools to get them to properly use the dependencies already installed on my platform. Wayne Hi Wayne, I think that sounds like a sane decision, although of course KiCad will be subject to the bugs in other libraries, but it's up to distribution maintainers to sort those out in my opinion. I hope that we can use some sort of deprecation system, please mark a lib as being deprecated so that I can sort out Winbuilder before the CMake system is broke. It's much easier to work that way round as opposed to a reactionary approach where we break everything and then everyone has to fix their build before being able to do anything. I will do the leg work to keep the Winbuilder people happy and do any projects necessary to package dependencies required by it. So far in august there have been 1685 builds using KiCad-Winbuilder. So at least people have been finding it useful! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Hello and helping out
On 14 August 2014 23:55, Derek Kozel derek.ko...@gmail.com wrote: Hello! First of all thank you to everyone who has contributed to getting KiCad to where it is now. I've made several boards with it and hope to make many more. I'm a recent EE/CS graduate with experience working on medium sized C++ projects, mostly in Linux. I'd like to give back to the project and the areas I think I can help with are: * Reviewing the open bugs and trying to link duplicates, recreate new ones, and test if old bugs have been fixed but not closed. For instance https://bugs.launchpad.net/kicad/+bug/593782 has been in progress for 3 years and appears to be a Will Not Fix. Is there a specific person who owns triage and bugs or is it open and I should proceed using my best judgement? * Reviewing and improving the main website For instance KiCad appears to no longer have a presence on Sourceforge, so the News, Press, and Sourceforge links are dead on the homepage. (http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite) There also are pages which could be improved both in content and organization I believe. Who should I talk with about this? * Updating the binary distribution of KiCad for Windows The version linked to from the homepage is from over a year ago. If this is the current Stable version, it seems like that should be explicitly stated and links to that version for the other OSes provided. I'd like to work with Brian Sidebotham or others from the winbuilder project to supply more recent binaries under the unstable/development label. Hi Derek, Thanks for your interest in KiCad. With regards to KiCad-Winbuilder, just shout for what you need. I think anyone could provide automated latest development binaries using KiCad-Winbuilder so long as they understand the environment it produces - i.e you must run it through the RunKiCad.bat file instead of running it directly, and it will not install like some people are used to. It's essentially a portable app. But please don't be afraid to approach me or get stuck in and send me patches for KiCad-Winbuilder for anything you want to do with it. I'm very open to help with it as since having our new daughter around time has become extremely scarce. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] eeschema modular kicad work
On 4 August 2014 17:05, Dick Hollenbeck d...@softplc.com wrote: I pushed an early branch of this work to milestoneB. See the commit log for some of the details. The shared_ptr turned out to be a can of worms. No, several cans of worms, all stacked like a 2 miles of dominos. So I used a single one per LIB_PART according to this link here, and saved us all a lot of gray hairs. This is a very elegant solution which cherry picks not one IOTA more than what we needed: http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/sp_techniques.html#weak_without_shared I pushed this to branch milestoneB and would appreciate some testing help. There are some TODO items in my section of TODO.txt for this block of work. Most notable is moving the Color loading into the eeschema KIFACE::OnKifaceStart(). Also, the libraries are loaded more often than they should be, I think SCH_EDIT_FRAME needs to quit deliberately loading them and simply use the data on demand technique. You can see schematic editor loading libraries even if you load the lib editor first. This is trivial to fix. I will fix those TODO items along with any bug reports and get 'em done soon. I also saw a segfault somewhere as I was leaving the room. Need to track perhaps a couple of these down. All in all, kicad is more modular, and there's lot to like here I think. Dick Hi Dick, Thanks so much for your conitnuing work - it doesn't go unnoticed - I'm sorry I've not had to time to say thanks more often. In this commit you fixed something that was on my list - creating a project from a template was broken in KiCad-Winbuilder. You happened to fix this in your commit, so I got to cross if off my list! Perfect, well done with all this work and seeing things like running the module editor and library editor from KiCad directly is a great example of what you've been heading towards - I had failed to see what real advantage we were going to end up with. Thanks again, take it easy! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Anti-aliasing for the 3D-Viewer
For the number of elements in an array, you can use: ./include/macros.h:#define DIM( x )unsigned( sizeof(x) / sizeof( (x)[0] ) ) which is more consistent in the KiCad source code. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] winbuilder debug build link fail
Hi Jason, Winbuilder doesn't currently support a debug version build. It's not a good development environment, but it does at least give you the dependencies you need to build KiCad on Windows successfully. The problem with the debug build is with Python as Python searches for different module names when built as debug as opposed to a release version - I don't remember the specifics. Some of the compiler definitions would probably have to be solved too for the Python debug build. At the time Dick and I discussed this and decided that it wasn't worth the effort when printf* is so useful, I tended to concur there, although sometimes stepping through code is the only way I can efficiently debug! If you want to build a debug version without python support, you can do that by linking against wxWidgets instead of wxPython. The binaries are available from the same launchpad project. I will update them to 3.0.1 as soon as I can. At the moment, they're a patched 3.0.0. If you want to build a version using your own toolchain, I heavily suggest you build the dependencies with that toochain too. The wxwidgets-cmake project, etc. make that very easy to do. * On windows, as the stdout pipe is dropped from a wxWidgets app I use OutputDebugString instead, it's a rather poor string output with no formatting, but you can add that in easily enough. You can see the output with DebugView. Lastly, although developing *for* windows is important, developing under Linux is just *so* much more productive! But I wouldn't want to discourage anyone who wants to work on Windows. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxWidgets 3.0
Thanks for the release information Dick, we'll look to include that in Winbuilder as soon as possible. At the moment the version used is a patched v3.0.0, not a vanilla version. Therefore some vital fixes for KiCad were already included. It will be good to upgrade to get the bug fixes though. Jason, Changing everything is likely just going to get you in more of a mess tbh, The toolchain included with Winbuilder is a mingw-w64 version from the mingw-builds project. It's a SJLJ version, be very careful using a different compiler with the other winbuilder dependencies. There's been some nasty bugs seen before when mixing toolchains. Everything in Winbuilder works, but it would seem in your instance the environment is different when running KiCad. You *must* run KiCad from the RunKiCad.bat start script included in winbuilder because that sets up the environemt. It's meant to be an isolated environment so that no install is required, but it looks like there's something that isn't isolated in your case. I would recommend taking the following steps: (1) File a full bug report on Launchpad for KiCad-Winbuilder ( I think this is definitely a Winbuilder bug, not KiCad ) (2) Build from a fresh download of KiCad-Winbuilder-3.4-2 on a local drive ( non-removable media ) (3) Attached the build logs from that build to the bug you reported on Launchpad. (4) If you can, get process monitor ( http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx ), start it and add a filter to only include items from a process called pcbnew.exe and then start PCBNEW from the KiCad program manager and report all entries in process monitor. This way we'll see the exact paths that the dynamic loader is trying to load _pcbnew.kiface from and also what dependencies that loads and where from too. Reporting the bug generally gets other people's input too because there's always more than one person suffering from the same problem. However, so far I've not seen anyone else experiencing this bug. Best Regards, Brian. On 30 June 2014 08:04, Jason Whiteman whitemanja...@gmail.com wrote: Thanks for the heads up -- this started me a bit down a rabbit hole. I've swapped out the winbuilder mingw with the mingw-w64-dgn personal build. He's got wxwidgets-3.0.1 pre-built. This brought gcc up to 4.8.3 (could have went the 4.9.0 way -- but decided to stay within the 4.8.x) and moved to an x64 compiler. This exposes a few pointers that need to be retyped for x64 - I'm working through that. Also, the dgn build doesn't come with OpenMP out-of-the-box. I think I have to install llvm perhaps. Not a big deal - only ratsnest uses is thus far in my compile -- so I #undef'd OpenMP out of the src. I've got it queued to go back and unpatch that - but at this point I'm just trying to sort through a w64 build. I'm sure this has been done many times over by others. Regards, Jason On Sun, Jun 29, 2014 at 7:58 AM, Dick Hollenbeck d...@softplc.com wrote: http://wxwidgets.org/news/2014/06/wxwidgets-3.0.1-released/ Is good news. I have seen quite a few bugs in the 3.0 release myself, and stopped using it after about a month. In my case, I simply use SVN HEAD. Might be a good idea if winbuilder would use this 3.0.1 version. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Build 4955 - Failed to load shared library
Hi Guys, I should first say, this is not typical of Winbuilder. Both pcbnew and cvpcb work fine for me on a fresh Windows 7 install using the github fp-lib-table. So there's clearly something different about your setup. Process monitor is (from sysinternals) is excellent at tracking dependency loading, so if you want to track what's getting loaded from where, that's the best tool for the job. If you use dependency walker make sure you run it from the console provided by enterenv.bat so that PATH is set the same as when kicad is run. I wonder what Y: is? Is winbuilder on a network drive? Can you move it to a local drive instead and run? I wonder if it's a permissions issue with regards to loading dependencies? Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] KiCad-Winbuilder V3.4 released
Hi Guys, KiCad-Winbuilder V3.4 is out which addresses a few issues. You can get it from the Launchpad project page: https://launchpad.net/kicad-winbuilder 3.4 11.06.2014 - BJS * Copy *.kiface files to the kicad/bin directory. Fixes bug 1315945 * Fix issue with checking for wxPython (was checking for 2.94 binary) * start kicad.exe instead of running it from RunKiCad.bat so that the console window is dropped (Thanks to Ian Woloschin). Fixes bug 1320512 * Use tee to be able to view progress of KiCad build instead of having a static display (Thanks to Ian Woloschin). Fixes bug 1327263 * Install xsltproc so that the xsl templates can be used. (Thanks to Peter Ogden). Fixes bug 1328339 * Install missing kicad.pro and other template files from the kicad source code (Thanks to Ed Johns). Fixes bug 1276387 * Issue a warning when the installed path length may be too long to build KiCad successfully. Fixes bug 1267057 For those who grabbed it early, it's worth grabbing the new 3.4-1 archive which fixes a couple of niggles in the initial 3.4 release from yesterday. Any problems, please use the bug tracker on Launchpad - it has been essential for me to know what to fix for the V3.4 release. Thanks to all those who took the time to report bugs and potential fixes it really helps me maintain the project. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Python Scripting Window event handling
I know I had this same problem with the python console on Windows. I don't t think this is something that changed, I think it's always been there. I can test on Windows tonight for you and let you know. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Moving field-texts with connecting line to component; potential patch
Hi Henner, Committed in BZR4686. Thanks again for your contribution. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: CvPcb - bring footprint window to front when it is buried
On 5 February 2014 17:18, Henner Zeller h.zel...@acm.org wrote: Hi, I usually have a lot of windows stacked on my desktop, which often obscures the 'footprint window' in CvPcb. Pressing the 'view selected footprint' brings the window up the _first_ time, but when it is already there, it stays buried - which is frustrating. So I created the following patch, that works well in Linux and does exactly how it should behave: bringing the window second in the stack of windows on the screen. The focus still stays on CvPcb, but the window is brought as much to the top as possible. I don't know if there is a special function in wxWidgets to achieve that, but the proposed method in the patch works fine. There is a slight chance that this might create a flicker-experience in some other OSes window managers, so please give suggestions how this could be worked around there, if it turns out to be a problem. View patch: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible Download: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible.diff Thanks, -henner Hi Henner, Thanks for the patch. I'll get round to testing it tonight. If it doesn't cause problems (I'm sure it won't) then I'll commit it for you. However, please note the coding style policy ( http://www.kicad-pcb.org/display/DEV/Getting+Started ) as we don't use this- to refer to class members, simply omit this- and refer to class members directly. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Moving field-texts with connecting line to component; potential patch
On 7 February 2014 10:31, jp charras jp.char...@wanadoo.fr wrote: Le 07/02/2014 09:22, Henner Zeller a écrit : Hi, While moving a field text (REFERENCE, VALUE and such) in the schematic, it is possible to loose the visual sight to which component it belonged to, in particular in tight spaces (which is typically the time when you need to start moving labels around). At least once I swapped the visual designators with different components .. creating a mess. So while moving such a label, I think it would be good if there was a visual indicator to which component that label belongs to -- a simple line would do. This would only be drawn while moving is in progress; see attached image how this could look like. I have prepared a patch that does that (the image is done with this patch): https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels As the way to draw differs for not-moving vs. moving (there is an additional line), the very first draw operation with XOR doesn't make sense, as the line hasn't been there before. Likewise the opposite when stopping moving. So here I keep a little state in the SCH_FIELD component that keeps track if the _last_ draw operation was seeing IsMoving(). I haven't found if there is a better way within the framework to better get informed about these transitions. If so, please point me how to implement that more elegantly. And as usual, here the patch download link: https://github.com/hzeller/kicad/compare/master...show-belongs-to-edge-while-moving-labels.diff cheers, -henner Good idea. This feature was existing in Pcbnew, but not in Eeschema. May I ask you to have a look to our coding style policy (see Documentation/coding_style_policy.pdf) before submitting a patch. Thanks for your interest in Kicad. This is a great feature, thanks for your interest Henner! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: CvPcb - bring footprint window to front when it is buried
On 7 February 2014 16:17, Henner Zeller h.zel...@acm.org wrote: On 7 February 2014 02:37, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 5 February 2014 17:18, Henner Zeller h.zel...@acm.org wrote: Hi, I usually have a lot of windows stacked on my desktop, which often obscures the 'footprint window' in CvPcb. Pressing the 'view selected footprint' brings the window up the _first_ time, but when it is already there, it stays buried - which is frustrating. So I created the following patch, that works well in Linux and does exactly how it should behave: bringing the window second in the stack of windows on the screen. The focus still stays on CvPcb, but the window is brought as much to the top as possible. I don't know if there is a special function in wxWidgets to achieve that, but the proposed method in the patch works fine. There is a slight chance that this might create a flicker-experience in some other OSes window managers, so please give suggestions how this could be worked around there, if it turns out to be a problem. View patch: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible Download: https://github.com/hzeller/kicad/compare/master...make-existing-footprint-window-visible.diff Thanks, -henner Hi Henner, Thanks for the patch. I'll get round to testing it tonight. If it doesn't cause problems (I'm sure it won't) then I'll commit it for you. thanks! Hi Henner, Committed in BZR4669 with very slight changes to the comments only. Thanks! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Revisiting the Git decision - document git-bzr bridge!
On 5 February 2014 22:35, Blair Bonnett blair.bonn...@gmail.com wrote: On 6 February 2014 10:31, Jake j...@spaz.org wrote: On Wed, 5 Feb 2014, Brian Sidebotham wrote: On 5 February 2014 10:11, Jake j...@spaz.org wrote: I just want to say the same thing that a lot of other people have been saying for a long time. Bazaar is holding kicad back. I am yet another developer who would be contributing to improving the project if it weren't kept in an arcane and frustrating VCS. So, if you're putting letters like this in a pile somewhere, just go ahead and put this one in the pile. I really would love it if kicad went to git, not just to make it easy for me to contribute, but for lots and lots of people who would jump in and help. thank you for everything you've done and all that you will do -jake Hi Jake, Did you read the whole of this subject? Go ahead and use Git if you want, no-one is going to stop you. Links have been provided on information to allow you to develop using Git. We look forward to your contributions. Best Regards, Brian. Hi Brian, I assume you're referring to git-bzr-ng which I was told about on irc. Supposedly this can allow a git user to interact with the bazaar system transparently. That would be great, except i can't get it to work. snip thank you -jake Hi Jake, I think Brian was referring to the GitHub mirror workflow that has been discussed in this thread in the last 24 hours. The following messages are the key ones in this workflow discussion: 1: https://lists.launchpad.net/kicad-developers/msg12148.html 2: https://lists.launchpad.net/kicad-developers/msg12159.html 3: https://lists.launchpad.net/kicad-developers/msg12160.html 4: https://lists.launchpad.net/kicad-developers/msg12161.html In fact, Henner has already submitted two patches to this mailing list based on this workflow, so it seems to be quite usable in practice. I guess we could document this workflow on the KiCad website, say under the KiCad development page ( http://www.kicad-pcb.org/display/DEV/KiCad+Development ). Maybe once the core developers have given their blessing that it works from their side as well? Regards, Blair Hi Guys, Sorry last night was wiped out with family stuff so I didn't get chance to update kicad-pcb.org. I will try and get it done tonight, but in the meantime use the instructions on the Inkscape developer wiki and let us know how you get on. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: In eeschema: use unused hotkey 'Backspace' to be equivalent to 'Delete'
Hi Henner, In EESCHEMA, under Preferences-Hotkeys-Edit Hotkeys, you can edit the hotkeys and set Backspace as the Delete function. However, I notice that changing the Delete function hotkey doesn't work. This in fact should be filed as a bug; So please file a bug report on Launchpad so it can be fixed, or else feel free to apply a patch that fixes this bug instead. The best method is to file a bug report on launchpad and issue a patch to fix it at the same time, but at least if there's a bug report someone else can maybe fix it before you get around to it. Thank-you for highlighting the issue. Best Regards, Brian. On 5 February 2014 05:02, Henner Zeller h.zel...@acm.org wrote: Hi, My notebook has a keyboard that doesn't have a 'Delete' key, only 'Backspace'. This makes deleting objects in eeschema quite cumbersome as this always requires to use the right-mouse button menu. Since 'Backspace' is not bound to anything in eeschema, this patch adds the Backspace key to be equivalent to the Delete key: removing the object under the cursor. View patch here: https://github.com/hzeller/kicad/compare/master...delete-and-backspace-equiv Download patch here: https://github.com/hzeller/kicad/compare/master...delete-and-backspace-equiv.patch Since I am new to this codebase, I am not sure if this is the right way to add another hotkey or if there is better way to get this same functionality. If everything is ok, then I'd be happy to see this added to upstream. Thanks, -henner ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: In eeschema: use unused hotkey 'Backspace' to be equivalent to 'Delete'
On 5 February 2014 14:15, Chris Morgan chmor...@gmail.com wrote: If there isn't a binding for the backspace key might it also make sense to have the default binding for 'delete item' be both backspace and delete by default? In addition of course to fixing whatever bug there is in the hotkey assignment. Chris I don't think so, because for example in PCBNEW for example the Backspace key and the Delete key have different functions. In PCBNEW when you press the Delete key, you delete an entire net and when you press the Backspace key you delete the current track segment only. This is really useful funcionality and I would rather reserve a future implementation of those separate functions associated to those two keys in EESCHEMA rather than apply two keys to the same function now. I've also not tested how two keys bound to the same function perform in the Hotkeys Editor - but I suspect not well. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: In eeschema: use unused hotkey 'Backspace' to be equivalent to 'Delete'
On 5 February 2014 14:39, Brian Sidebotham brian.sidebot...@gmail.com wrote: I've also not tested how two keys bound to the same function perform in the Hotkeys Editor - but I suspect not well. Sorry, scrap that last comment, of course it would be absolutely fine. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: In eeschema: use unused hotkey 'Backspace' to be equivalent to 'Delete'
On 5 February 2014 15:54, Henner Zeller h.zel...@acm.org wrote: On 5 February 2014 06:11, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Henner, In EESCHEMA, under Preferences-Hotkeys-Edit Hotkeys, you can edit the hotkeys and set Backspace as the Delete function. Uh, life can be so simple at times :) However, I notice that changing the Delete function hotkey doesn't work. mmh, I just tried it, and it actually worked: went to hotkeys, selected the field with 'Del' in it and pressed Backspace. That worked for me. This was compiled from head. Only difference could be the wxWidgets version ? I am using it with 2.8; I shall try with a newer version to see if that is working. Excellent, then it's already fixed. I'm on a laptop with BZR4016 installed, so I could only test in that version. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: In eeschema: use unused hotkey 'Backspace' to be equivalent to 'Delete'
On 5 February 2014 15:54, Nick Østergaard oe.n...@gmail.com wrote: However, I notice that changing the Delete function hotkey doesn't work. This in fact should be filed as a bug; So please file a bug report on Launchpad so it can be fixed, or else feel free to apply a patch that fixes this bug instead. The best method is to file a bug report on launchpad and issue a patch to fix it at the same time, but at least if there's a bug report someone else can maybe fix it before you get around to it. There is already similar stuff already reported. This could be related, without looking too much into it. https://bugs.launchpad.net/kicad/+bug/706361 Hi Nick, That's different, two functions for one hotkey. That would require macro support - because you'll need to control the order of functions. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Revisiting the Git decision
I suspect it's all just a documentation issue too as someone else suggested because it's so easy to branch the code and generate a patch using Bazaar. Perhaps the best place for anyone who has decided Bazaar is dead (it works for me by the way!) and therefore cannot contribute (and particularly git fans) is to look at the Inkscape wiki: http://www.inkscape.org/en/develop/getting-started/ Or, you can just... bzr checkout lp:kicad bzr branch ./kicad ./kicad-feature ..hack, hack, hack kicad-feature, you can commit to ./kicad-feature as many times as you like and merge in the tip any time you want to keep conflicts to a minimum... cd kicad bzr up cd .. cd kicad-feature bzr merge ../kicad bzr diff my-feature.patch It's really that easy to start contributing (I've left out the build and debug steps which are several orders of magnitude more time consuming). You don't need to fork, pull, push or anything like that. I agree, we should probably have a wiki page similar to Inkscape's, but Inkscape has many more contributors compared to KiCad. PCB design is less popular than vector graphics in general. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Revisiting the Git decision
On 4 February 2014 13:04, Joel Holdsworth j...@airwebreathe.org.uk wrote: Hi All, Thank you all for taking the time to respond to my original e-mail. It seems to me that whatever the outcome this discussion it is well worth having. On 04/02/14 11:57, Brian Sidebotham wrote: I suspect it's all just a documentation issue too as someone else suggested because it's so easy to branch the code and generate a patch using Bazaar. Agreed, as James Hagerman put it The KiCad website and KiCad Launchpad page are full of broken or misleading links to old, outdated, or conflicting information. Binaries (and libraries) for all platforms are not readily available on either site. I found that to be true for myself. For example I spent a lot of time trying to get the adamwolf PPA to work for me - but it's hopelessly out of date. Unfortunately, everyone is trying their best - but we're struggling for resource. The codebase has been extremely volatile lately with regards to adding in dependencies, there's been a great effort by a lot of people to keep build systems working and stable, but it's a large task and may not settle down for a while yet as KiCad moves through some pretty major changes. It wouldn't take much effort to fix this, just a bit of polish; sorting through what is current, and what is out of date. Perhaps the best place for anyone who has decided Bazaar is dead (it works for me by the way!) and therefore cannot contribute (and particularly git fans) is to look at the Inkscape wiki As I said, of course Bazaar still works - Hell CVS still works! But that doesn't mean it would be doing you any favors if you stuck with a CVS workflow. That's my point - it's a loss of opportunity. I do hope someone brings Bazaar back on track - truly! Competition in this space is good and healthy. But what do you think? Do you think that's likely? I hope to be wrong, but I suspect I won't be. And there are some big warning signs: emacs switching away from it, the loss of developer mind-share, stalled development - these are quite serious, and so I'd recommend taking care not to dismiss them to lightly. Let me ask - do you think Bazaar has a bright future at this point? I don't consider Bazaar to be off-track I guess, and my workflow sits in with Bazaar commands easily. So it's future is exactly the same as it's present state, even if there is never another commit to it - it does what is needed for me at least. ...snip... There are a couple of things I'd like to have also. Are these things possible? I sent the other link very much on purpose, as on that page, a few paragraphs in is a link to this page: http://www.inkscape.org/en/develop/using-git-repositories/ in other words, fill your boots, work with Git on the KiCad codebase if you want, there should be nothing stopping you. Yes, we could document this feature ourselves, but none of the lead developers (as far as I'm aware) use git-bzr-ng for developing with git branches. You should find that any of your preferred Git workflows are possible using git-bzr-ng. If you have the time, please try the git workflow and see if it does work for you. If it does, then great - we can make a big song and dance about it and let everyone know that they can develop with Git workflows, it would be valuable information for us! I agree the website could do with some updates, the sourceforge link is dead, the freshmeat link is meaningless, the developers page is out-of-date, etc. We're doing our best, but need more help with things such as documentation and website maintainence, etc. It's a struggle to find time to write any actual code! Just email a unified patch per feature (preferably not a patch set, because they're harder to review quickly) to the developers list starting the subject with PATCH: Thank-you for your interest, and taking the time to join the developers list and discuss... Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Building KiCad on windows
Hi Guys, It's always worth when you can filling in bug reports against KiCad-Winbuilder. It helps focus my time and makes we aware of things I don't know about. Although I can't fix the internal MinGW error (Which I've never seen!), seeing a bug report means I probably would have bumped the compiler up to 4.8.2 which has been out for a while now. I didn't move to the next release of MinGW in KiCad-Winbuilder-3.3 because I'd never seen any problems with 4.8.1 - it's likely 4.8.2 has a tonne of bugfixes in it though. KiCad-Winbuilder tries to be as isolated as is possible under Windows so as not to be affected by any system versions or settings, but clearly differences can still be present. Out of interest Travis, how much RAM do you have installed? Sometimes problem arise because of lower spec's. I have an Intel Core i7 (so essentially 8 cores), and 16Gb RAM with a PCIe SSD - it's a quick and capable system. Building KiCad is intensive on RAM use, particularly when using parallel build jobs. Usually you get out-of-memory errors, but sometimes you just get odd behaviour and crashes instead depending on each allocation's error handling. Best Regards, Brian. On 3 February 2014 04:31, Travis Ayres tray...@gmail.com wrote: It looks like one of the errors is an internal MinGW error when I try to build. Attached are some of my logs from the build process of Kicad-Winbuilder. -Travis On Sun, Feb 2, 2014 at 9:49 AM, Simon Turner si...@simonsphotography.org.uk wrote: OK build success but I have to start kicad with the runkicad.bat file ? What have I actually done ? can I transfer this to other computers or move it on my current computer ? I opened the CvPCB program and it can't find any pcb footprints, is this all due to upgrading to the latest version that does things differently or is something broken ? Simon On 02/02/2014 15:49, Simon Turner wrote: whoops might be I got in a muddle and used the old winbuilder version, trying again... Simon On 02/02/2014 15:44, Simon Turner wrote: OK It's been running, yes on windows 7 I now have: CMake error at kicadwinbuilder.cmake:1110 file: file COPY cannot find C:/kicad-winbuilder-3.2/src/library/library- press any key to continue So I got some sort of a build out of it, the layout of the kicad manager window is a bit messed up, the program icons are too far left and encroach on the file list and some are missing. The PCB program won't start because it can't find libcairo-2.dll, the icons for the programs to the left of it are missing. Oh and does it really need to take up 2.5GB of space ? Simon On 02/02/2014 13:54, Milan Horák wrote: Hi, I'm happy to hear this. Did look into your logs - it seems like there was problem with too long path to a file required to compile process. Shortening the path should help (seems it did). Milan Dne 2.2.2014 14:29, Simon Turner napsal(a): Well I put it in C: and it's still building long after it would have died so must be working. Thank you, let you know how it turns out. Simon On 02/02/2014 12:42, Simon Turner wrote: I have, and the previous logs were from it but I was not in C: so I'm running again from C: Simon On 02/02/2014 12:35, Milan Horák wrote: Hi, you should download latest kicad-winbuilder (version 3.3) - https://launchpad.net/kicad-winbuilder Milan Dne 2.2.2014 12:43, Simon Turner napsal(a): See coments below On 02/02/2014 11:28, Milan Horák wrote: Hi, it should be simple (read 'Works for me'): - Enter 'kicad-winbuilder/env' directory and run 'make.bat' *No make.bat in this folder, using the one from the main folder does not work* - Wait for the script to finish - In 'kicad-winbuilder' directory run 'make.bat' *Thats all i was trying but got errors, log files attached* - In 'kicad-winbuilder' directory run 'RunKiCad.bat' *ok haven't done that yet and the make fails* Milan Dne 2.2.2014 11:50, Simon Turner napsal(a): I tried but got errors and was told to check the logs that told me nothing other than error2 and error3, I just gave up. I ended up with 1.25GB of cmake files and stuff and noactual programs. I found the instructions a bit minimal, any chance of a better instruction being written for it ? Simon On 01/02/2014 21:52, Ed Johns wrote: Simon, Have you tried using kicad winbuilder? It has the full build environment which downloads the latest source. It is on launchpad as well. - Ed On Feb 1, 2014 4:47 PM, Simon Turner si...@simonsphotography.org.uk mailto:si...@simonsphotography.org.uk wrote: Hello All Just thought I'd raise something. It seems that the time between releases is lengthening as more work is being done to make things much better. I did once manage to build a fresh version of KiCAD on ubuntu and was very pleased with the progress but this was the only way of getting the most up to date features. I have since abandoned ubuntu
Re: [Kicad-developers] KiCad-Winbuilder V3.3
On 30 January 2014 16:52, Wayne Stambaugh stambau...@verizon.net wrote: On 1/30/2014 6:59 AM, Brian Sidebotham wrote: Hi Guys, I've just uploaded a new release for KiCad-Winbuilder which includes a few fixes and bumps wxPython up to V3+ (V3.0.0 with a couple of patches mentioned on the KiCad developers list which are useful fixes for KiCad). The library now also comes from GitHub (Simply by downloading the master zip file every time). I wanted to move the APPDATA stuff into the KiCad-Winbuilder environment so that it was all self-contained but wxWidgets makes use of the CSIDL_* constants obtained through the Windows API rather than using the more common APPDATA environment path, so I can't redirect that. It may be better that it's not re-directed anyway. I tested last night and everything appeared to work okay. Whilst building our house and especially when our new baby arrives I might have to leverage support from users of the script to help maintain it. If anyone's interested in improving or helping maintain the build system please don't hesitate to get in contact. I have appreciated all the bug reporting that has gone on recently as the script fell out-of-sync with KiCad's changes - it really helps focus my time on fixing things rather than discovering things. A new house and a baby on the way and he still finds time to hack on KiCad! You are now officially on my hero list. Thank you Brian for you dedication to the KiCad project. Your help is greatly appreciated. Wayne Thank-you Wayne, but know that it's entirely mutually felt! It still amazes me, that the other day I was able to layout a project for a charity to enable them to bring micro hydro-electric generators to places that have no other available power source in a very capable package entirely written and supported by volunteers. It should make everyone involved feel proud to have delivered that project. Thank-you to all involved! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Building KiCad on windows
Hi Travis, KiCad-Winbuilder uses the MinGW-w64 distribution (which is what you'll find on most Linux distributions too these days): http://mingw-w64.sourceforge.net/download.php#mingw-builds The MinGW install check is redundant these days, ever since I packaged the environment with MinGW-w64, this is necessary because you may have a different ABI or different exception model variant installed and the downloaded wxPython release is built with mingw-w64-4.8.1-sjlj. The path is sanitised in make.bat (via setenv.bat) so KiCad-Winbuilder can never detect any other MinGW you have installed. Best Regards, Brian. On 3 February 2014 17:43, Travis Ayres tray...@gmail.com wrote: Brian, How would you have bumped up the requirement for MinGW to 4.8.2? I just checked on TDM-GCC, and I don't see the upgrade to 4.8.2 (although TDM is repackaged MinGW, so it might not be fully up to date). I just looked at the KiCad-Winbuilder CMake file, and I think I'm running 4.8.1 because of my locally installed MinGW. Is there a way I could execute KiCadWinbuilder.cmake with the mingw_local_NOT_FOUND = 1? I'm re-running KicadWinbuilder on a machine with more memory to see if I get different results. I'll let everyone know the results. On Mon, Feb 3, 2014 at 2:52 AM, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Guys, It's always worth when you can filling in bug reports against KiCad-Winbuilder. It helps focus my time and makes we aware of things I don't know about. Although I can't fix the internal MinGW error (Which I've never seen!), seeing a bug report means I probably would have bumped the compiler up to 4.8.2 which has been out for a while now. I didn't move to the next release of MinGW in KiCad-Winbuilder-3.3 because I'd never seen any problems with 4.8.1 - it's likely 4.8.2 has a tonne of bugfixes in it though. KiCad-Winbuilder tries to be as isolated as is possible under Windows so as not to be affected by any system versions or settings, but clearly differences can still be present. Out of interest Travis, how much RAM do you have installed? Sometimes problem arise because of lower spec's. I have an Intel Core i7 (so essentially 8 cores), and 16Gb RAM with a PCIe SSD - it's a quick and capable system. Building KiCad is intensive on RAM use, particularly when using parallel build jobs. Usually you get out-of-memory errors, but sometimes you just get odd behaviour and crashes instead depending on each allocation's error handling. Best Regards, Brian. On 3 February 2014 04:31, Travis Ayres tray...@gmail.com wrote: It looks like one of the errors is an internal MinGW error when I try to build. Attached are some of my logs from the build process of Kicad-Winbuilder. -Travis On Sun, Feb 2, 2014 at 9:49 AM, Simon Turner si...@simonsphotography.org.uk wrote: OK build success but I have to start kicad with the runkicad.bat file ? What have I actually done ? can I transfer this to other computers or move it on my current computer ? I opened the CvPCB program and it can't find any pcb footprints, is this all due to upgrading to the latest version that does things differently or is something broken ? Simon On 02/02/2014 15:49, Simon Turner wrote: whoops might be I got in a muddle and used the old winbuilder version, trying again... Simon On 02/02/2014 15:44, Simon Turner wrote: OK It's been running, yes on windows 7 I now have: CMake error at kicadwinbuilder.cmake:1110 file: file COPY cannot find C:/kicad-winbuilder-3.2/src/library/library- press any key to continue So I got some sort of a build out of it, the layout of the kicad manager window is a bit messed up, the program icons are too far left and encroach on the file list and some are missing. The PCB program won't start because it can't find libcairo-2.dll, the icons for the programs to the left of it are missing. Oh and does it really need to take up 2.5GB of space ? Simon On 02/02/2014 13:54, Milan Horák wrote: Hi, I'm happy to hear this. Did look into your logs - it seems like there was problem with too long path to a file required to compile process. Shortening the path should help (seems it did). Milan Dne 2.2.2014 14:29, Simon Turner napsal(a): Well I put it in C: and it's still building long after it would have died so must be working. Thank you, let you know how it turns out. Simon On 02/02/2014 12:42, Simon Turner wrote: I have, and the previous logs were from it but I was not in C: so I'm running again from C: Simon On 02/02/2014 12:35, Milan Horák wrote: Hi, you should download latest kicad-winbuilder (version 3.3) - https://launchpad.net/kicad-winbuilder Milan Dne 2.2.2014 12:43, Simon Turner napsal(a): See coments below On 02/02/2014 11:28, Milan Horák wrote: Hi, it should be simple (read 'Works
Re: [Kicad-developers] Building KiCad on windows
On 3 February 2014 18:38, Milan Horák stran...@tiscali.cz wrote: Hi, and I am compiling KiCad on VirtualBox Windows XP machine, limited to one core of Phenom 955 and 512MB RAM :-) Milan Ha! I'm impressed that works at all, but fair enough. With only a single core you can't eat too much memory I guess! Nice work Milan! Take it easy, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] KiCad-Winbuilder V3.3
Hi Guys, I've just uploaded a new release for KiCad-Winbuilder which includes a few fixes and bumps wxPython up to V3+ (V3.0.0 with a couple of patches mentioned on the KiCad developers list which are useful fixes for KiCad). The library now also comes from GitHub (Simply by downloading the master zip file every time). I wanted to move the APPDATA stuff into the KiCad-Winbuilder environment so that it was all self-contained but wxWidgets makes use of the CSIDL_* constants obtained through the Windows API rather than using the more common APPDATA environment path, so I can't redirect that. It may be better that it's not re-directed anyway. I tested last night and everything appeared to work okay. Whilst building our house and especially when our new baby arrives I might have to leverage support from users of the script to help maintain it. If anyone's interested in improving or helping maintain the build system please don't hesitate to get in contact. I have appreciated all the bug reporting that has gone on recently as the script fell out-of-sync with KiCad's changes - it really helps focus my time on fixing things rather than discovering things. This is partially compounded by the fact that the default OS in my bootloader is now Linux. However, I do not intend that to detract from supporting KiCad-Winbuilder. Everyone should upgrade as soon as possible. The first build takes ages, so just let it run overnight. CMake still has issues on Windows creating the keyword files and some other header files without error when using parallel jobs. Therefore if those files have not yet been created, the build defaults to no parallel jobs! Sorry I can't do anything to resolve that issue at the moment. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad-Winbuilder V3.3
Thanks Miguel, it will be our first so we're very excited as well as desperately trying to at least complete the bathroom as soon as possible! We are expecting at the beginning of May. Many congratulations to you too, good luck with everything yourself! Best Regards, Brian. On 30 January 2014 12:21, Miguel Angel miguelan...@ajo.es wrote: Good work Brian, volunteers to help, please stand up! ;) When's the new baby arriving?, we're expecting for Mid-April... First one?, 2nd one?... Very good luck, and congratulations!. Cheers, Miguel Ángel. --- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2014-01-30 Brian Sidebotham brian.sidebot...@gmail.com: Hi Guys, I've just uploaded a new release for KiCad-Winbuilder which includes a few fixes and bumps wxPython up to V3+ (V3.0.0 with a couple of patches mentioned on the KiCad developers list which are useful fixes for KiCad). The library now also comes from GitHub (Simply by downloading the master zip file every time). I wanted to move the APPDATA stuff into the KiCad-Winbuilder environment so that it was all self-contained but wxWidgets makes use of the CSIDL_* constants obtained through the Windows API rather than using the more common APPDATA environment path, so I can't redirect that. It may be better that it's not re-directed anyway. I tested last night and everything appeared to work okay. Whilst building our house and especially when our new baby arrives I might have to leverage support from users of the script to help maintain it. If anyone's interested in improving or helping maintain the build system please don't hesitate to get in contact. I have appreciated all the bug reporting that has gone on recently as the script fell out-of-sync with KiCad's changes - it really helps focus my time on fixing things rather than discovering things. This is partially compounded by the fact that the default OS in my bootloader is now Linux. However, I do not intend that to detract from supporting KiCad-Winbuilder. Everyone should upgrade as soon as possible. The first build takes ages, so just let it run overnight. CMake still has issues on Windows creating the keyword files and some other header files without error when using parallel jobs. Therefore if those files have not yet been created, the build defaults to no parallel jobs! Sorry I can't do anything to resolve that issue at the moment. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad-Winbuilder V3.3
Hi Adam, For Jenkins it should be just a case of downloading KiCad-Winbuilder-3.3, and point a Jenkins job at make.bat and then stuff some file manipulation on the end to zip the relevant files into an archive. It'll be pretty large though and you'll need to include things like RunKiCad.bat, etc. as the launcher which creates a local KiCad environment for running. Good Luck and let me know if you need any help or anything. Best Regards, Brian. On 30 January 2014 14:54, Adam Wolf adamw...@feelslikeburning.com wrote: I would like to volunteer to help out with the Windows build and add it to the Wayne and Layne Jenkins cluster. Is there good documentation for setting it up and building it, including what sort of Windows stuff you need? I am very inexperienced with Windows. On Thu, Jan 30, 2014 at 8:18 AM, Edwin van den Oetelaar oetelaar.automatiser...@gmail.com wrote: Congratulations to both your families. This will be the most import (and busy) part of your life. Greetings, Edwin On Thu, Jan 30, 2014 at 3:13 PM, Brian Sidebotham brian.sidebot...@gmail.com wrote: Thanks Miguel, it will be our first so we're very excited as well as desperately trying to at least complete the bathroom as soon as possible! We are expecting at the beginning of May. Many congratulations to you too, good luck with everything yourself! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] testing has been renamed to product
A new version of KiCad-Winbuilder will be released in the next few days. I haven't tried it since the change to product from testing, but there will only be a few references to testing, if any. The new version includes the library from github, and has wxPython 3 + a few patches. Best Regards, Brian. On 20 January 2014 21:33, Travis Ayres tray...@gmail.com wrote: You can probably still use the same computer though :) Haha thanks Dick :) I appreciate it. On Mon, Jan 20, 2014 at 11:51 AM, Dick Hollenbeck d...@softplc.com wrote: On 01/20/2014 01:32 PM, Travis Ayres wrote: My branch.conf file: parent_location = http://bazaar.launchpad.net/~brian-sidebotham/kicad-winbuilder/trunk/ bound_location = http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/ bound = True When I said run $ bzr bind lp:kicad I meant in the kicad source working tree, not in the winbuilder working tree. You evidently have two working trees with a winbuilder setup, and now the winbuilder tree is broken, so you are doubly broke. Fixing the winbuilder tree: $ cd winbuilder tree $ bzr bind http://bazaar.launchpad.net/~brian-sidebotham/kicad-winbuilder/trunk/ Fixing the kicad source tree: $ cd kicad src tree $ bzr bind lp:kicad After both are fixed, you have a prayer. If this does not work, I am out of ideas. Start over is what I would say. You can probably still use the same computer though :) ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] DRC pads
The allowance of overlapping pads in the DRC is pretty essential at the moment because KiCad cannot do polygon pads or multiple drill holes (as Wayne pointed out). Therefore when people require unusual pad shapes they end up making them out of overlapping pads, relying on the current behaviour. However, this is always within the same module. Overlapping pads with the same net in different modules is probably a case we should be flagging with the DRC. So I think it would be better to add to this check to make sure the pads are in the same module in order to pass. If the pads are on the same net but in different modules, that should be considered an error/warning. That's my opinion at least. This would improve the DRC results while not creating a lot of noise for essentially valid designs. Best Regards, Brian. On 17 January 2014 11:57, ml m...@dasir.net wrote: I believe this case should be better solved by creating a 3 pad footprint and corresponding schematic symbol instead of putting away the most common requirement for nonoverlapping parts. Anyway I see that there are such unusual needs :-) I can implement a checkbox in the Design Rules Editor dialog labeled Allow overlapping pads within the same net with default off. In the future I can add an option for each pad. Any suggestions before I start? David Yes and no, sometimes you want something like two resistors for pulling a pin high/low - and you only need it in one configuration. Saving space, one might do something like #=# # instead of #=#-# #. Problems may arise with THT pads, if the holes are not perfectly overlapping (worst case, snapped drill in production). I would opt for a warning or even better, something configurable like the ERC in eeschema. imp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bzr is unmaintained. Should we move KiCAD repository to git too?
On 3 January 2014 14:09, Chris Morgan chmor...@gmail.com wrote: I'm not actively making changes but in case it helps someone else, here is what was confusing me. This is something I do a few times a day with git in order to keep history clean and integrate patch review feedback. How to get upstream changes while making local changes (or if I had a few local commits)? Just merge the current tip: bzr merge lp:kicad The other thing I couldn't figure out was how to modify local changes, and how to modify changes that were one or more changes behind my latest change. So if I wanted to build up a patch series how do I clean that up based on feedback or things I've learned along the way? ... - commit X (upstream HEAD) - commit 1 (local change) - commit 2 (local change / local HEAD) How to modify commit 1? Changing your workflow here will probably help if you want to work on different features at the same time, rather than trying to shoehorn that into one feature per commit, which I guess is what you're trying to achieve. Just branch locally as it's cheap: bzr branch ./kicad ./kicad-newfeature-1 bzr branch ./kicad ./kicad-newfeature-2 etc. Then commit locally as many times as you like in each feature. If you're doing parallel development and need both changes simultaneously, you could branch again and merge both features in, etc. Don't use bzr like git or svn or rcs or anything else, it's bzr and git's git! They do not have direct translation to one another. It might help to document how to map these operations from git to bzr on the kicad page to help get people familiar with git up-to-speed. Contributing to KiCad is extremely easy given you only have to branch, make changes and then create a patch and email it to the list. Please feel free to use this easy method to contribute your first changes. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] various patches
On 2 January 2014 03:27, Cirilo Bernardo cirilo_berna...@yahoo.com wrote: Hi folks, I have put two sets of patches onto github for anyone to review or apply. The (bzr) patches: export_idf3.patch : Adds basic IDF3 export (board and cutouts / holes only) export_vrml.patch : Improved VRML export; includes more realistic coloring scheme, zone fills, improved eye candy. This patch is better than the patch I previously posted here; this patch fixes a number of bugs, eliminates a redundant class, and provides features such as the zone fills and silver pads. Hi Cirilo, Thanks for this work, the IDF export may well be something I could use. So thanks for contributing! :D Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boost dependencies
This did break KiCad-Winbuilder, but I released an update with libbz2 building enabled. So it's all good. From the Boost Documentation: On Windows, the zlib and bzip2 filters are disabled by default; to enable support for these filters, you will need to set variables indicating the location of the source files, if building from the source, or the location of the headers and binaries, if using pre-built binaries. http://www.boost.org/doc/libs/1_54_0/libs/iostreams/doc/installation.html So it seemed reasonable to include it now in case we need it in the future for some reason. Best Regards, Brian. On 16 November 2013 13:43, jp charras jp.char...@wanadoo.fr wrote: Le 16/11/2013 12:27, Maciej Suminski a écrit : I cannot explain why, it was just an observation - I attach the log that made me think so. Does it break builds on Windows? Regards, Orson On 11/15/2013 10:01 PM, Brian Sidebotham wrote: This dependency is not required on Windows? How come the Linux build needs it and the Windows build doesn't? What boot library was throwing the error? Best Regards, Brian. Does it break builds on Windows? Currently, yes, because under Windows it is not needed, and if this dependency is added, one should build and add this lib to mingw. Under Windows, I removed this dependency. In fact, when you build boost libs, the files used to build them are not exactly the same between Linux and Windows. So the fact bzip2 is needed on Linux and not on Windows is curious, but no fully surprising. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boost dependencies
This dependency is not required on Windows? How come the Linux build needs it and the Windows build doesn't? What boot library was throwing the error? Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] footprint library help needed
On 13 November 2013 17:51, Carl Poirier carl.poirie...@gmail.com wrote: Coming from Mercurial, I prefer branch, commit, push rather than checkout, commit. :P Pushing with Bazaar is horrible. It works while you're the only editor, but once other people start pushing too it will likely all fall over. You're better off checking out to a local directory with something like (assuming kicad-lib is whatever you're working on!) bzr co lp:kicad-lib Then branch locally: bzr branch ./kicad-lib ./kicad-lib-updates Work in kicad-lib-updates committing as many times as you want and using version control locally. Occasionally it's good to update kicad-lib with bzr up and then merge any changes to your local branch to make sure there aren't any conflicts or people working on the same stuff as you. Then when you're ready to commit: cd kicad-lib bzr up bzr merge ../kicad-lib-updates ... Resolve any outstanding conflicts ... bzr commit -m My Updates This is more like my work flow with Bazaar anyway, and it allows you to branch multiple-times locally so that you can work on several different features at once. Local branches are extremely cheap and throwaway. Branching from a remote location is not cheap. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] boost gcc 4.8.1
On 11 November 2013 10:49, Maciej Sumiński maciej.sumin...@cern.ch wrote: Then it may be related to Linux exclusively, as I use 64 bit too and the error occurs. More details can be found at: https://svn.boost.org/trac/ boost/ticket/8973 Regards, Orson Hi Orson, It may be. I just looked at the mingw32-w64 stdint.h and it unconditionally defines int64_t and uint64_t so there's going to be no problem with it being defined using that compiler. The problem seems specific to some stdint implementations. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] github roll-out plans
Search for valvers-pcb Fifth result is the github repository I setup as a test when the Github plugin was coming to fruition. So I think github indexing works fine for personal repo's. The key is to get something searchable that is reasonably unique. Everything before this is old stuff that I must tidy up. Searching for kicad_mod tyco multilock also returns the correct result (Top answer this time as it's so specific) so there's mileage in Google in being the library browser of choice. Best Regards, Brian. On 9 November 2013 04:31, Dick Hollenbeck d...@softplc.com wrote: On 11/08/2013 03:51 PM, Carl Poirier wrote: I meant get something out of Google. Without waiting for 10 months. Its possible there's simply a delay. But here's another theory: What if google's policy is to *not ever* index personal github repos, on the theory it is too much, too fleeting, and that a personal repo is often a fork of a project repo? Then you will wait forever. There are about 2 million repos on github. Isn't a project repo, on the other hand, one that is registered with github as a project? I am wondering if they only index project repos as a policy decision. It would make sense to me. Search for github kicad Resistor_SMD2010_ReflowWave_RevA_Date21Jun2010.kicad_mod, you'll see it doesn't get you anything, On Fri, Nov 8, 2013 at 3:49 PM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: At github there are personal repos and project repos. If I google for github kicad base_screen.cpp I find the file base_screen.cpp, which is from a 10 month old copy of our launchpad repo lodged in a *project* repo. There is hope, don't know if its the personal vs. project repo that factors into the google policy or not. BTW, here are the mug shots of the project owners: https://github.com/KiCAD?tab=members All two of them. Thanks for your time Carl. You will be hearing a lot more of that from others in the near future. I'm experimenting with Google Search and for now the GitHub repos under my name don't seem to get indexed at all. I've searched in many different ways, including the most obvious ones. I'll see how we can get something out of it. On Fri, Nov 8, 2013 at 11:58 AM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com mailto:d...@softplc.com mailto:d...@softplc.com wrote: Switching from openssl thread to a new one: With GITHUB_PLUGIN now available to ~ 90% of the KiCad user base (omitting OSX?), I now look forward to folks putting footprint libraries on github and bragging about them, under the leadership of Carl Poirier, who has scripts and know how on how to publish them so that they can be installed by a single copy and paste through a webbrowser into the fp-lib-table editor. I look forward to that affecting my productivity in a positive way, so that I can spend less time looking for footprints, and more time making boards. I would look forward to collaboration on sharing the pretty on github publishing know how on kicad-pcb.org http://kicad-pcb.org http://kicad-pcb.org in the form of documentation, and a link to that write up making it to the kicad-user mailing list. Because I think this would spur more sharing, and yet again help my productivity in making boards. Question: does google index any of the github content, or is it simply too much? If yes, then this is yet another way to find KiCad specific footprints rapidly after this publishing gets some legs. You should be able to google for kicad_mod package_name and turn up something. I think it would be great if we could gather up some prizes (cash, goodies) of some kind, and award them to a best footprint library maintainer every six months or so. OK, it's out there, now I hope the community can run with this stuff, OK !? (I've got programming work and board work to do. No time for library management, and I don't have the expertise either.) ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe :
Re: [Kicad-developers] OpenSSL-CMake build system
On 23 October 2013 14:57, Dick Hollenbeck d...@softplc.com wrote: Brian, If it works for you, it works for me. I want your life as easy as possible! Plus if it works for you, it works for Windows users, and that brings them use of the GITHUB_PLUGIN, so I am happy all around. Hi Dick, Excellent, I'm committed these changes in BZR4447 IMO, it is also good for openssl. But you know how folks are with their build systems. (Folks like sticking with what they know.) Some comments: a) pcbnew/github/CMakeLists.txt will continue to use find_package( OpenSSL REQUIRED ) on linux. This is the path of least resistance for that platform. Agreed. b) The path chosen on OSX seems unclear to me, but as written, github/CMakeLists.txt will route OSX builders to find_package() as well, meaning they will have to install openssl in advance of the build. I don't know OSX, the possibility to use your openssl build system is on the table, but just guessing, it seems they will prefer a pre-built package like on linux. c) You commented out the toolchain statement. I know Orson and others are cross building the entire KiCad for Windows on Linux. To me it seems we need to pass the CMAKE_TOOLCHAIN_FILE setting in, on the assumption that if it is blank, it won't break the native build. You will confirm that upon re-enabling it. I commented this out because CMake barfs if you pass CMAKE_TOOLCHAIN_FILE as a blank value. I left it in, but commented out for exactly this sort of feedback. I've included it in a conditional which checks to see if CMAKE_TOOLCHAIN_FILE is blank. d) Seems to need another new line at end of file, see very bottom. It builds on the excellent work you did on downloading and building openssl, I was passing the baton, knowing and hoping you'd step in and make it work for the most difficult platform. Trying to save you some initial work. You continue to be an MVP. Dick Excellent, this is now in place in BZR4447. KiCad-Winbuilder 3.1 (Literally minutes old) now includes support for the GAL default build as well as enabling FP_LIB_TABLE and GITHUB_PLUGIN so as to maximise the exposure of those features to beta-testers. There are easy-to-configure options in KiCad-Winbuilder to disable these options if someone wants to run the latest KiCad build without them enabled. We should now expect feedback on those features to increase. Thanks very much to Orson who did the changes necessary for KiCad-Winbuilder to successfully build the GAL code. A quick, simple merge was all that was necessary! Lovely! Now I'm looking forward to getting some boards done, and getting some work done on the regression testing too. Something other than build systems would be nice for a while! CMake continues to comfort me where autotools used to kick me in the shins regularly. The CMake documentation is also excellent, very complete and concise. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] OpenSSL-CMake build system
On 8 November 2013 16:42, Dick Hollenbeck d...@softplc.com wrote: I commented this out because CMake barfs if you pass CMAKE_TOOLCHAIN_FILE as a blank value. I left it in, but commented out for exactly this sort of feedback. I've included it in a conditional which checks to see if CMAKE_TOOLCHAIN_FILE is blank. Well done, perfect solution. one extra comment line we don't need now, due to your magic and amazing build system work on OPENSSL: # this requires that perl be installed: Any luck getting this CMake work accepted upstream on any of your numerous upstream CMake efforts? Oops, missed that comment. I've removed it now. There hasn't been any luck in getting the CMake build systems integrated into any of the projects yet, but to be fair I haven't really put in any effort to get patches accepted. Most require some additional work before approaching the project developer lists because of known missing feature support. For example, the wxWidgets CMake build system is lacking support for building a GTK version on Linux and that's used quite heavily. Once that support is in place it would probably be worth asking them. Then of course there'd need to be an equivalent of wx-config as this is a bash script and doesn't work on Windows without a bash shell. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Announcement
Excellent work guys! I'm really looking forward to trying this stuff out. I'll commit the download_openssl.cmake changes in a few days when we're back on-line at home as I've just moved house and we've no internet access at home at the moment. Thanks to everyone involved in that work, a push and shove router, the GAL and the tool framework is all excellent news for KiCad!! Best Regards, Brian. On 30 October 2013 01:29, Wayne Stambaugh stambau...@verizon.net wrote: Now that the repo is back in good shape following my lapse in judgement (Thanks Dick!) I am happy to announce that the CERN OpenGL/Cairo rendering, push and shove router, and the new tool framework code has been committed to the testing branch for widespread testing and development. Please note that building kicad has changed slightly on some platforms. Here are the revised build instructions: - Linux: it builds exactly the same as always - Windows: cross compilation (http://www.ohwr.org/documents/251) and native build using mingw (http://www.ohwr.org/documents/300) - Mac OS: http://www.ohwr.org/documents/293 Please note that most of the Pcbnew editing tools have not been ported to the new framework. Therefore, most of the editing has to be performed in the default rendering mode. It will take some time for this to happen so please be patient as this work continues. I want to personally thank the folks at CERN who made all of this possible. Enjoy, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] OpenSSL-CMake build system
Hi Guys, I attach a diff which uses a new OpenSSL-CMake project I registered on Launchpad to provide a CMake build system on-top of OpenSSL. I started with the LuaDist project's CMake system and patched it to work with the OpenSSL 1.0.1e release. This means that all of the if( MINGW ) tests and the like in CMakeModules/download_openssl.cmake go away and we end up with a common build system for all systems. It should work for all systems. Hopefully we can use this build system instead of the horrible PERL one. It's probably not the most complete build system in the world - but it appears to do the job admirably. I tried openssl speed to stress test the library build with the CMake build system and everything looked good. I need to test it on Linux, and I don't have a MAC box to test on, but I can't see anything that shouldn't work - everything's pretty generic. It's a shame launchpad release file URL's are so verbose - I didn't bother trying to put the version number variable in it, it's probably easier to just change that URL when the MD5 and version variables are changed. Dick, does this look good to you? It builds on the excellent work you did on downloading and building openssl, but it also wipes out quite a bit of work you'd already done. This does mean we are in control of the build in the same way on all platforms though, and of course, it's a CMake build system too! I will try to contact the OpenSSL guys and see if they are in any way keen to have a CMake build system contribution. Best Regards, Brian. openssl-cmake-kicad.diff Description: Binary data ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Building OpenSSL with CMake on Windows
I patched the LuaDist CMake build system to work successfully on OpenSSL 1.0.1e. Downloading, patching and building OpenSSL with CMake on Windows has an issue though (Doesn't everything being built on Windows!?) The issue is that CMake, or more precisely libarchive used by CMake doesn't deal with symbolic links on Windows. Even 7z doesn't deal with them at all well either. The source archive for OpenSSL includes symbolic links in the include directory. 7z outputs an ascii file with a line of text that is the relative path to the actual file. Not very useful, but this was at least parse-able and therefore fixable in CMake. CMake -E tar fails with the message: Cannot create \. There's plenty of information about this, and a fix is targeted at the 2.8.12 release: http://www.cmake.org/Bug/print_bug_page.php?bug_id=13251 It may work okay under the MSYS shell actually - I've not tried as I don't have it. I'm unsure how we will get around this problem on Windows. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Building OpenSSL with CMake on Windows
On 16 October 2013 12:04, Dick Hollenbeck d...@softplc.com wrote: On windows, can you try downloading from github the doctor-ed zip file like the person in the bug report said? Lets put that bug report URL in our download script too as a comment. Okay, I will do that. The zip file is awkward. It simply has nothing in place of the symbolic links, so the include directory is empty. I can modify the cmake scripts to populate it when it doesn't exist, or the patch can contain the include files. In the latter case the patch sits around 1.5Mb! I think I'll do the magic in the CMake script to populate the include directory if it is empty, and our patch step will apply the CMake files only. I'll add the bug report URL into our download_openssl.cmake too. It's a shame, it just makes a neat External_Add into a mess of if( MINGW ) crap. Ideally I wanted this CMake build system to work on top of the .tar.gz so it could be a common build step for all platforms. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] MASM Boost dependency on Windows
On 15 October 2013 01:55, Lorenzo Marcantonio l.marcanto...@logossrl.comwrote: On Mon, Oct 14, 2013 at 10:45:38PM +0100, Brian Sidebotham wrote: Yes, MinGW has GNU AS (It's part of binutils). I don't know why they've implemented it with MASM instead for the Windows platform. Problem: gas uses ATT syntax, not MASM one. YASM/NASM could be a better bet. So? The syntax isn't a reason as they've used GNU AS for the linux port. But probably they choose MASM to use some Windows-specific trickery? The context classes IIRC are for coroutine so they only should do stack/register freezing but who knows... I suspect it's more a case of their Windows developer being familiar with MASM and so he wrote what he was comfortable in; But maybe there were other issues that forced their hand. Having said that, the ATT syntax is absolutely awful. As Dick says, this completely breaks cross-compilation of Boost. Wasn't MASM deprecated/unsupported for a long time anyway? It still appears to be a current download from the Microsoft website. I've committed the change to temporarily disable building the context library until we can have a patch in place or similar to compile Boost with just GNU tools when using MinGW. I'll have a look at the GAL/PS branch to see if we can pull this stuff in - unless it will get pulled in when these branches get merged in? Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] MASM Boost dependency on Windows
On 15 October 2013 16:07, Maciej Sumiński maciej.sumin...@cern.ch wrote: On 10/15/2013 03:33 PM, Lorenzo Marcantonio wrote: On Tue, Oct 15, 2013 at 02:18:19PM +0100, Brian Sidebotham wrote: As Dick says, this completely breaks cross-compilation of Boost. Well, can't say it is a good thing... as a workaround maybe supplying precompiled (preassembled!) object for that couple of file could be useful, too. I am just wondering - don't those files included in the CERN branch ( http://bazaar.launchpad.net/~**cern-kicad/kicad/testing/** files/head:/common/system/http://bazaar.launchpad.net/~cern-kicad/kicad/testing/files/head:/common/system/) solve the problem? If no - what is wrong with them, maybe we can introduce some modifications? I was able to build the KiCad using these files on every supported platform (actually the tool framework and the push and shove router depends on them). Regards, Orson Hi Orson, Those files are basically the patch provided on the Boost bug tracker I originally linked to as far as I can tell. Having read all of that conversation now I think in order to support boost::context in KiCad that patch is the only way we're going to get it to build under MinGW. Olli from the Boost project looks to have misunderstood the original bug report which is Boost::Context doesn't build with MinGW! - instead he's contorted it in an attempt to blame a problem in the MinGW linker. Binutils (and thus GNU AS) is part of MinGW, it's a part of the toolchain so requiring MASM is just a fallacy. We best include the patch in our source tree. To be fair, it won't be hard to maintain that patch as it's unlikely they'll change that assembler code, and swapping from one assembler flavour to another isn't exactly difficult, it's just a syntax change. Alternatively, we could investigate setjmp/longjmp pairing to do the context switching and patch that onto Boost. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] MASM Boost dependency on Windows
I know it's only our own fault for being on Windows but the Rev 4382: *) Switch over to FP_LIB_TABLE::Footprint*() functions commit introduces the need for the Microsoft assembler, MASM to be installed to be able to build Boost. It's the context library that brings in this dependency. The only reason it's awkward is because there's no way I can redistribute or package it, and the only way of getting it is through Microsoft's website as a setup.exe package via confirmation links. i.e. we can't just use a fixed URL to download it anyway as far as I'm aware. We could try to use the patch here: https://svn.boost.org/trac/boost/ticket/7262 but it's against an older version and will bit rot. The boost guys don't seem to be at all bothered and don't see it as an issue. I don't know if there are other ways around the problem? I'm just working on the openssl cmake patch so we can build it ourselves using cmake, thus cutting out the perl dependency. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] MASM Boost dependency on Windows
On 14 October 2013 22:36, Dick Hollenbeck d...@softplc.com wrote: For now just comment out context. We won't need it until building GAL PS. Does mingw come with an assembler. Does it suppprt inline asm? Ther are only a coulple of small files to assemble. Enabling context was a trial balloon. Seems to have accomplished its goal. Excellent, will do. Yes, MinGW has GNU AS (It's part of binutils). I don't know why they've implemented it with MASM instead for the Windows platform. Thanks for the quick response Dick. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] export of cad file
On 8 October 2013 16:00, Wayne Stambaugh stambau...@verizon.net wrote: On 10/8/2013 8:20 AM, Thomas Spindler wrote: Hi Guys, I had to do some tricky mechanical design around a pcb and generated a step like file format. (See attached example) If other users find it useful I will eventually integrate it into 3d-viewer. Thomas Thomas, It certainly looks interesting. When you say a step like file format, I'm assuming you mean a step file format. I opened the attached file with Freecad without any issues so it must be step like enough. Does your step generator include the component models as well as the board? This has been a frequently requested feature for KiCad so it would be nice to have if you are willing to see it through. Your initial results are impressive and it's something I would find useful. Thanks, Wayne It also imports into Solid Edge ST6 as a step file as well. Excellent work Thomas! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Fwd: Re: Kicad-Spice simulation tutorial
On 6 October 2013 18:39, Dick Hollenbeck d...@softplc.com wrote: -- Forwarded message -- From: Matan Gal-Katziri mata...@gmail.com Date: Oct 5, 2013 11:44 PM Subject: Re: Kicad-Spice simulation tutorial To: Nacho Domínguez domal...@gmail.com Cc: Miguel Angel Ajo Pelayo miguelan...@nbee.es, Fabrizio Tappero fabrizio.tapp...@gmail.com, Dick Hollenbeck d...@softplc.com, Miguel Angel miguelan...@ajo.es Hi Guys, I had a little time this weekend to arrange my thoughts and write a coherent documentation of what I did. Conclusions: 1. I think it covers procedures that might look obvious to advanced users. 2. This is my preferred working method and not an absolute truth. Others might not like it. 3. If KiCad could create sub-circuits out of hierarchies where local hierarchical labels are the pins it could be great for integration purposes, don't know if it's on your roadmap though. Anyway, I attach a preliminary PDF of what I did. If you still find the content helpful I can convert it to your file format, review and upload to the repository.. Best regards, Matan Gal-Katziri Hi Dick, I was interested in reading Matan's PDF to see how he was using SPICE simulation with KiCad. Could you attach the pdf he refers too, either just pop me a private email, or send direct to the list if you think others will be interested in it. SPICE is another thing that's been on my list for a long time, but something I've never got round to with KiCad. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Github plugin.
On 7 October 2013 05:56, Dick Hollenbeck d...@softplc.com wrote: On 10/06/2013 06:05 PM, Brian Sidebotham wrote: On Windows, building without the msys environment means perl is an absolute no-go area for me; Android cell phone found this this morning, while I was laying in bed. I guess it wanted to be relevant, helpful, and to cmake a difference: https://github.com/LuaDist/openssl Hi Dick, Thanks for this link. KiCad-Winbuilder just puts the 1.0.0d release of the luadist openssl project in it's environment and points the OPENSSL_ROOT_DIR variable to the install. This works well - so there's no need for me to create a separate project. The Luadist openssl binary release is compiled to rely only on msvcrt, so there are no C-Runtime library conflicts. We could easily use this project through ExternalProject_Add to if we preferred that approach. Best Regards, Brian. The audience most likely to be dissappointed with the current setup is a KiCad Windows builder person that is not using KiCad-Winbuilder. I am not in that audience, so I am not the best spokesperson for their pain. The only pain I'd have to suffer is if you were thinking of bringing in all the source for that lua openssl project into KiCad and adding it to our tree. I'd prefer not to do that. There are quite a number of alternatives all of which would use ExternalProject_Add(). Someday in the next year or so we could rely on the new CMake 2.8.11 support of https:// downloads. That would get you the most recent zip file from github, but it would not pin the version number. Each download would be today's version. Alternatively, you could strip out all the CMake scripts into a patch and apply that patch into a pristine (older?) openssl download using ExternaProject_Add(). Having that patch in our tree (dir: /patches) would not bother me at all. Hi Dick, This alternative would be my favourite choice. I think we can just extract the CMake scripts, tidy them a bit because they use the old style CMake install commands, and also remove the Luadist specific stuff and we should be able to easily patch them on top of a vanilla OpenSSL source. The OpenSSL source is very stable, I think the only changes they make are to close buffer overflow and other security risks, so the source code file set remains predominately unchanged between releases. I'm more than willing to do this and it would be more in keeping with our CMake build system. Then, we could submit it to openssl folks and ask them (no doubt again) to offer a sensible build system for poor Windows builders. You would think the lua guy that did all that work did that, but who knows. Piling on seems appropriate in any case. The only thing I've been afraid of is to push Windows builders into using patch.exe. You scared me away from that. So we went with bzr patch, but that only works in a bzr working tree. So I've had to check in anything needing to be patched into a scratch repo, just to establish a working tree. LOL, why is patch.exe not included as part of Windows? Thank goodness we have you Brian to sort this all out. I agree, Windows is lacking a lot. It's a shame bzr patch requires a working tree. That is a pain. The original problems with patch.exe were coming from the Windows User Access Control layer which prevents access to any executable called patch.exe! However, it can be circumvented by having a manifest file alongside the executable which reassures Windows. So just something to trip the normal user up with no enhancement what-so-ever! Thank goodness for projects like CMake, mingw-w64 and the like!! That's the only way any of these builds are possible. Plus of course, thanks to you and everyone else for building everything so solid on top of CMake so that just a bit of tweaking is needed to get things building on Windows! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Github support for mingw-w64
On 7 October 2013 05:32, Dick Hollenbeck d...@softplc.com wrote:
Hi Brian,
You have a total comprehension of what is going on, and your solution has
left the linux
build working. So I would say thank you for an excellent job. I would
hope windows users
would say the same.
Comments below.
Excellent, glad that's the case - I don't mean to waste your time asking
you to look at everything. It's good to get the feedback before the commit
at the moment though. Thanks for taking the time to review the changes.
Remove this if() block:
+if( MINGW )
+set( GITHUB_ADDITIONAL_LIBS ws2_32 )
+endif()
+
# No, you don't get github without boost and openssl
target_link_libraries( github_plugin
${Boost_LIBRARIES}
${OPENSSL_LIBRARIES}
+${wxWidgets_LIBRARIES}
remove this:
+${GITHUB_ADDITIONAL_LIBS}
)
and replace it with this trailing additive statement:
if( MINGW )
target_link_libraries( github_plugin
ws2_32
)
endif()
add_dependencies( github_plugin boost )
Perfect, that looks more obvious regarding what's going on. Thanks.
As an aside, I noticed that some targets such as libpcbcommon and
libpolygon have a header-only dependency on boost. CMake won't know about
that dependency. Although CMake doesn't encounter the problem at the moment
I think with many parallel build processes it may be possible that one of
those targets gets built before boost has been installed. Should I add the
add_dependencies( target boost ) command for those targets? I think it
appears best to do it.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Interesting DLL Hell with SSL
On 4 October 2013 08:55, Maciej Sumiński maciej.sumin...@cern.ch wrote: Hi Brian, In fact it looks very strange.. I am just wondering - wouldn't it be easier to link OpenSSL as a static library? It may require a rebuild in the KiCad-Winbuilder, but then you will not have to care about stuff that users keep in Windows directory. Regards, Orson Hi Orson, While static linking would be a band-aid, it seems a bit poor to have to resort to static linking, especially as the project is moving more towards shared objects for everything. Static linking will give us multiple copies of the same code which isn't great (especially if the code requires large amounts of const data like look-up tables the like), but also shared objects give us good code separation. I think we could in the future move to patching the OpenSSL vanilla source and build it as part of the KiCad build (As has now been mentioned in another thread). At that point we're in control of the library name. We could call it libeay32-kicad.dll for example and we'll remove ourselves from DLL hell. I'd prefer to head down this route in the future. It's right that if we compile something, we get to name it. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Github plugin.
On Windows, building without the msys environment means perl is an absolute no-go area for me; Android cell phone found this this morning, while I was laying in bed. I guess it wanted to be relevant, helpful, and to cmake a difference: https://github.com/LuaDist/openssl Hi Dick, Thanks for this link. KiCad-Winbuilder just puts the 1.0.0d release of the luadist openssl project in it's environment and points the OPENSSL_ROOT_DIR variable to the install. This works well - so there's no need for me to create a separate project. The Luadist openssl binary release is compiled to rely only on msvcrt, so there are no C-Runtime library conflicts. We could easily use this project through ExternalProject_Add to if we preferred that approach. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Github support for mingw-w64
No problem, good luck in the Tennis tourney!
On 5 October 2013 16:43, Dick Hollenbeck d...@softplc.com wrote:
Thanks. Will get back to you.
In tennis tourney today.
On Oct 5, 2013 9:20 AM, Brian Sidebotham brian.sidebot...@gmail.com
wrote:
Hi Guys,
Attached is the current patch I can commit to enable Github plugin
support for MinGW.
It enables OpenSSL, which can be pointed to by setting the
OPENSSL_ROOT_DIR when configuring with CMake. I've not done any work on
getting OpenSSL to compile under windows as it cross-compiles under Linux
just fine.
The boost build steps are a bit different to Linux and OSX. On windows we
need to specify library subsets to b2 rather than bootstrap using a --with-
prefix for all required libraries.
The installation of boost headers is slightly different under MinGW too,
we end up with an include directory of ${BOOST_ROOT}/include/boost-1_54/
instead of just the include base directory.
There were some linking problems with github where I had to add
${wxWidgets_LIBRARIES}. I guess that is safe to do across all platforms?
boost::asio requires us to link in a socket layer under MinGW too, so
ws2_32 is added for MinGW only.
Dick, if you've got time to review, could you give me your views and any
suggestions for change?
I should also add - this will not work with mingw32 as far as I have
tested. The compilation of a subset of boost libraries does not work for me
under the mingw32. This is probably a major problem as I expect most people
who are using MinGW are still using the MinGW32 project and not the
mingw-w64 project. With mingw32 using dwarf-2 though it doesn't really make
any sense to me to use that project.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Various HAVE_ISO_* in CMakeModules/config.h.cmake
Hi Guys, This plays breaks compilation with mingw-w64, can I remove them? I don't think they should affect anyone anymore because they are a MicroSoft Visual C cludge as far as I can tell. Mingw-w64's problem is that is defines both snprintf and _snprintf symbols. #cmakedefine HAVE_ISO_SNPRINTF #if defined( HAVE_ISO_SNPRINTF ) #define snprintf _snprintf #endif I guess MSVC only defined _snprintf and not snprintf? Anyhoo, if we don't want to get rid of them, I'll need to add a check so that the define is not used on mingw-w64 Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Interesting DLL Hell with SSL
This project: http://tibcoadmin.com/tibco/activematrix-businessworks/problem-with-libeay32-dll-and-ssleay32-dll/ has seen this behaviour too, and also concludes that the PATH is ignored in the search for the library. Their solution is to copy their DLL and overwrite the one in SysWOW64! lol. What a mess. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Various HAVE_ISO_* in CMakeModules/config.h.cmake
On 3 October 2013 23:41, Cirilo Bernardo cirilo_berna...@yahoo.com wrote: From: Brian Sidebotham brian.sidebot...@gmail.com To: KiCad Developers kicad-developers@lists.launchpad.net Sent: Friday, October 4, 2013 8:19 AM Subject: [Kicad-developers] Various HAVE_ISO_* in CMakeModules/config.h.cmake Hi Guys, This plays breaks compilation with mingw-w64, can I remove them? I don't think they should affect anyone anymore because they are a MicroSoft Visual C cludge as far as I can tell. Mingw-w64's problem is that is defines both snprintf and _snprintf symbols. #cmakedefine HAVE_ISO_SNPRINTF #if defined( HAVE_ISO_SNPRINTF ) #define snprintf _snprintf #endif I guess MSVC only defined _snprintf and not snprintf? Anyhoo, if we don't want to get rid of them, I'll need to add a check so that the define is not used on mingw-w64 Best Regards, Brian. A few thoughts on the matter: (1) MSVC 2010 and earlier only define _snprintf; I can't speak for any later versions. (2) #define snprintf _snprintf is what MinGW used to do when I last used MinGW 7+ years ago. This is *incorrect* behavior; MicroSoft's _snprintf implementation is bd; one behavior that's guaranteed to bite you in the ass is that if the source string is longer than the destination, the destination is filled with the source characters until the end of the destination - there is no terminal \0 (yay buffer overflow!) If I recall correctly there are other nuisances with the return value of _snprintf. The best workaround is to define a snprintf() function which wraps _snprintf_s() to provide the specified behavior of snprintf(). MS have marked _snprintf as deprecated, so just don't use it. MS have been promising since at least 2008 to make it simply disappear. (3) Given the comments in (2), if MinGW still uses #define snprintf _snprintf and you want to support MinGW compilation, you will need to disable the MinGW definition somehow. - Cirilo Cheers Cirilo - I noted that their _snprintf was indeed flawed and hardly safe! Mingw-w64 doesn't do #define snprintf _snprintf exactly, they actually have two slightly differing definitions. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Github plugin.
On 30 September 2013 00:13, Dick Hollenbeck d...@softplc.com wrote: Any problems getting GITHUB_PLUGIN to build? To run? Did you need to separately install the OPENSSL root certificates? Thanks for reporting your findings and your hard work. Dick Hi Dick, I just tested with BZR 4358 and everything looks good - I was able to check using your https://github.com/liftoff-sr/pretty_footprints test library. With regards to OpenSSL, there's no need to install the root certificates. The Github plugin runs with without setting the OPENSSL_CONF environment variable too. Everything appears to *just work*! I will roll a patch and pass it under your nose in the next few days before committing. There's only a few changes, my main problem was trying to get boost built and installed correctly. This is all fine now with the move to mingw-w64. I have a few things to tidy up before the patch is any good. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Github plugin.
On 30 September 2013 00:13, Dick Hollenbeck d...@softplc.com wrote:
On 09/29/2013 05:43 PM, Brian Sidebotham wrote:
On 26 September 2013 15:07, Dick Hollenbeck d...@softplc.com mailto:
d...@softplc.com
wrote:
On 09/26/2013 04:51 AM, Brian Sidebotham wrote:
On 22 September 2013 05:37, Dick Hollenbeck d...@softplc.com
mailto:d...@softplc.com mailto:d...@softplc.com mailto:
d...@softplc.com
wrote:
On 09/21/2013 09:23 PM, Dick Hollenbeck wrote:
I will fix it if it does not work on linux
Did that, it works now, and brilliantly.
We had a namespace collision on FPL_CACHE, my destructor was
going into
LEGACY_PLUGIN's
FPL_CACHE destructor. Linker did not catch that, because
geez, it was thinking
it was the
same class. Have given each FPL_CACHE class a unique name,
could have used a
namespace
but did not.
Then, I removed PCAD from FP_LIB_TABLE dialog, which does not
support Footprint*()
functions. *In its place I added Github plugin.* This was
me pulling the
trigger.
It works now. And it is really exciting.
*I am all for getting our stock footprints on github ASAP!*
Whoever is in charge of those now, please lets rock the
footprints!
Please talk to your platform sponsor about getting the PLUGIN
to run on the
Windows and
OSX platforms. I don't have those, and will not be helping
more than I have. I
wrote
CMakeModules/download_openssl.cmake and it might work with
minor edits if you
have perl on
your windows system because the damn openssl Configure program
uses perl.
Otherwise if
you have access to precompiled openssl libs and headers
another way, you can
force the
issue at or around line 31 of pcbnew/github/CMakeLists.txt by
defining
OPENSSL_INCLUDE_DIR and OPENSSL_LIBRARIES cmake symbols.
Sort of like this:
set( OPENSSL_INCLUDE_DIR
${PREFIX}/include
CACHE FILEPATH OPENSSL include directory
)
set( OPENSSL_LIBRARIES
${PREFIX}/lib/libssl.a
${PREFIX}/lib/libcrypto.a
CACHE STRING OPENSSL libraries
)
On Windows, building without the msys environment means perl is an
absolute no-go
area for
me;
Android cell phone found this this morning, while I was laying in
bed. I guess it wanted
to be relevant, helpful, and to cmake a difference:
https://github.com/LuaDist/openssl
This above project wrote a CMakeLists.txt tree for openssl. It could be a
lower hurdle
for someone determined to build openssl on windows, since it does not
require perl to
build openssl, presumably only CMake.
Boost on Windows per Brians findings below, I guess.
I am building OpenSSL on Linux using mingw-w64. I swapped Winbuilder
over to mingw-w64
sjlj. Everything builds and works correctly now. I'll create a patch in
the next few days
once I've tested a bit more.
Boost wasn't building correctly (well actually, as I mentioned on Stack
Overflow - it
doesn't install correctly) with the original mingw toolchain. However,
it does with
mingw-w64. So that ended up being a good move anyway to satisfy the
boost build step.
The first thing I got was an IO_ERROR exception from PCBNEW because the
kicad folder
didn't exist for the fp-lib-table. Once I created the folder the
fp-lib-table file was
created along with a message telling me it had been created.
Application startup-time is massively improved after moving to the
mingw-w64 toolchain
too. I guess the dwarf-2 unwind tables take a while to setup, sjlj
doesn't have to create
them. However, that is merely a reasonable guess. I suggest that anyone
using mingw moves
to mingw-w64 as soon as possible. I think the old mingw project is
loosing traction quickly.
Any problems getting GITHUB_PLUGIN to build? To run? Did you need to
separately install
the OPENSSL root certificates?
Thanks for reporting your findings and your hard work.
Dick
Hi Dick,
No problems getting GITHUB_PLUGIN to build. I've not connected it to a
github repository as I run out of time last night to generate a library.
I'll have a look at it tonight and see how things go.
I haven't installed any of the root certs for OpenSSL, but thanks for
pointing that out incase I stumble across that type of problem.
I'm sure I'll have some more information in the next day or so. The only
real issues were mingw, building openssl - the cmake effort you pointed at
did make the cmake implementation look very easy for the openssl build btw!
Then it was just boost library
