Yeah that was my thoughts. Include in the tarball the old and the new names.
On Wed, Dec 7, 2016 at 4:38 PM, Nick Østergaard wrote:
> Yeah, I don't know what is the best solution. But alternatively we
> could also just include them in the tarball, if we don't want it to
> "pollute" the github ki
Yeah, I don't know what is the best solution. But alternatively we
could also just include them in the tarball, if we don't want it to
"pollute" the github kicad org.
These tarballs:
http://downloads.kicad-pcb.org/libraries/
2016-12-07 22:28 GMT+01:00 Carl Poirier :
> Aah, I see now. I had missed
Aah, I see now. I had missed the part that the fp-lib-table didn't get
updated along the new install.
We indeed decided to keep the pretty names the same but with Github's
redirection, I missed the local uppgrade use case. What I can do is restore
a copy of the pretties with the old name. This way
Hi all,
I wrote this patch to allow users who cannot use avhttp for some reason to
compile the *stable*
branch using curl instead of avhttp, when using github plugin.
I tested it on W7 and Kubuntu 14.04.
However the more tests the better.
Please test it and see if there are issues (I could hav
Hello all,
one question might have drowned a bit: is there any particular reason
why kicad builds executables and libs into their own private directories
in first place rather than into a "bin" directory that I should be aware
off? It will help all considerations when I don't miss the importan
On 12/7/2016 1:52 PM, Nick Østergaard wrote:
> Yes, but lets use the windows use case. A user has 4.0.4 intalled and
> have fp-lib-table that matches the one used there for local libs. He
> then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an
> update with a package manager and pos
Yes, but lets use the windows use case. A user has 4.0.4 intalled and
have fp-lib-table that matches the one used there for local libs. He
then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an
update with a package manager and possibly osx too), the fp-lib-table
is a user preference
Well, if I use all the libs as local pretties, using the fp-lib-table that
has been tagged the same will work, won't it? Do we want to support mix and
matching tags?
On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard wrote:
> Well, the issue os the fact that if a user has choosen (one way or the
>
This is what I was looking for. Thank you for taking the extra effort
to figure this out.
Cheers,
Wayne
On 12/7/2016 1:38 PM, Michael Steinberg wrote:
> Hello,
>
> sorry for the noise, yes, the test cases can themselves be organized
> into suites inside the test-executable with Boost.Test (Tes
On 12/7/2016 1:05 PM, Michael Steinberg wrote:
> Hello Wayne, and others too of course!
>
>> I'm fine with copying the binaries to a single directory. It's not very
>> elegant but it's probably the path of least resistance. I'm surprised
>> cmake doesn't have a way to temporarily add build libs
Hello,
sorry for the noise, yes, the test cases can themselves be organized
into suites inside the test-executable with Boost.Test (Test-trees so to
say), so we're free to build a gazillion of executables per module or
collect them inside one executable and add a CTest-test for each suite
whi
Hello Wayne, and others too of course!
I'm fine with copying the binaries to a single directory. It's not very
elegant but it's probably the path of least resistance. I'm surprised
cmake doesn't have a way to temporarily add build libs for testing
purposes. Maybe they do and I'm just not awar
Hi Heikki,
Good catches, thank you for the report. Both issues should be already fixed.
Regards,
Orson
On 12/07/2016 01:11 PM, Heikki Pulkkinen wrote:
> Hi
>
> Yesterday I do some work with Via Stitching cleanup. Cleanup Tracks and
> Vias has been changed quite much past two weeks. I found that
Well, the issue os the fact that if a user has choosen (one way or the
other) to use all of the local libs he needs to update the fp-lib-table
manually. An option is to copy the renamed pretty fors to the old name as
to not generate errors for the user.
Den 07/12/2016 13.21 skrev "Carl Poirier" :
On 12/7/2016 4:29 AM, Maciej Sumiński wrote:
> Hi Michael,
>
> On 12/06/2016 05:35 PM, Michael Steinberg wrote:
>> Hello,
>>
>> I played around a bit and settled on a quick&easy solution. For running
>> the tests on windows binding to the shared libs is a problem with our
>> default build, because
On 12/6/2016 11:35 AM, Michael Steinberg wrote:
> Hello,
>
> I played around a bit and settled on a quick&easy solution. For running
> the tests on windows binding to the shared libs is a problem with our
> default build, because we have separate output directories per target.
> Only after an in
Hi,
On Wed, Dec 07, 2016 at 07:21:32AM -0500, Carl Poirier wrote:
> The KIGITHUB variable leads to Github. For using the pretties locally, the
> fp-lib-table.for-pretty has to be used instead, which is the one that's
> included by default in the stable release. Anyway, as I had mentioned in
> ano
The KIGITHUB variable leads to Github. For using the pretties locally, the
fp-lib-table.for-pretty has to be used instead, which is the one that's
included by default in the stable release. Anyway, as I had mentioned in
another thread very recently, the Github plugin is not even built in the
stable
On 12/07/2016 10:55 AM, Maciej Sumiński wrote:
> On 12/07/2016 10:35 AM, Michael Steinberg wrote:
>> Hello Orson,
>>
>>
>> Am 07.12.2016 um 10:29 schrieb Maciej Sumiński:
>>> I used to work with projects that had multiple small unit tests and it
>>> was quite neat solution. Do you think it would be
On 12/07/2016 10:35 AM, Michael Steinberg wrote:
> Hello Orson,
>
>
> Am 07.12.2016 um 10:29 schrieb Maciej Sumiński:
>> I used to work with projects that had multiple small unit tests and it
>> was quite neat solution. Do you think it would be much harder to apply
>> the same rules here? If so,
Hello Orson,
Am 07.12.2016 um 10:29 schrieb Maciej Sumiński:
I used to work with projects that had multiple small unit tests and it
was quite neat solution. Do you think it would be much harder to apply
the same rules here? If so, I would not mind having one-to-one relation
between targets and
Hi Michael,
On 12/06/2016 05:35 PM, Michael Steinberg wrote:
> Hello,
>
> I played around a bit and settled on a quick&easy solution. For running
> the tests on windows binding to the shared libs is a problem with our
> default build, because we have separate output directories per target.
> Only
22 matches
Mail list logo
