On 7/20/20 8:28 PM, Steven A. Falco wrote:
On 7/20/20 6:01 PM, Ian McInerney wrote:
You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install
It does look like it is that easy. I should have a build in another hour or
so. Then I'll
On 7/20/20 6:01 PM, Ian McInerney wrote:
You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install
It does look like it is that easy. I should have a build in another hour or
so. Then I'll load it into a VM and test. If that works o
Good luck.
I've been putting off updating the Audacity spec file that I am maintainer
on because of the cmake macro changes. But in my case I have to rewrite the
entire spec to use cmake since they removed their autotools-based build
system and instead introduced a broken cmake build system now -
There should be no differences with where things get installed to - and if
there are then our "install" targets are incorrect and should be fixed
upstream. The changes to the cmake macros are simply for the build system.
-Ian
On Mon, Jul 20, 2020 at 11:04 PM Steven A. Falco
wrote:
> On 7/20/20
On 7/20/20 6:01 PM, Ian McInerney wrote:
You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install
Then the builds and install will automatically use the proper out of tree
directory. See the change proposal page for more details:
htt
On 7/20/20 5:37 PM, Seth Hillbrand wrote:
Hi Steve-
This looks like a build setup issue, not in our CMake code. We can build out
of tree (in fact, we really prefer it) right now. From the log, the broken
command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
-DCMAKE_C_FLAGS_RELEASE:STRIN
You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install
Then the builds and install will automatically use the proper out of tree
directory. See the change proposal page for more details:
https://fedoraproject.org/wiki/Changes/CMake_to_
On 7/20/20 5:34 PM, Nick Østergaard wrote:
What does this mean if I want to test this locally?
Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...
To test locally, I use our kicad
Re: that.. https://www.spinics.net/lists/fedora-devel/msg274669.html
Quote from an Igor:
I'm confused by the proposal, it is named "CMake to do out-of-source builds"
but the macros seems to do the opposite?
On Rawhide (local repo):
%__cmake \
-S "%{_vpath_srcdir}" \
-B "%{__cma
I am not sure I misunderstand the terminology here, but "cmake -S . -B
foo -Dnickersej" looks "in tree" to me.
On Mon, 20 Jul 2020 at 23:37, Seth Hillbrand wrote:
>
> Hi Steve-
>
> This looks like a build setup issue, not in our CMake code. We can
> build out of tree (in fact, we really prefer i
Hi Steve-
This looks like a build setup issue, not in our CMake code. We can
build out of tree (in fact, we really prefer it) right now. From the
log, the broken command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRIN
What does this mean if I want to test this locally?
Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...
On Mon, 20 Jul 2020 at 23:28, Steven A. Falco wrote:
>
> Fedora recently mad
Fedora recently made a change to their cmake macros, to force packages to build "out
of tree". The developers responsible for this change plan to go through and fix up
the thousand or so packages that may break as a result, so they should eventually fix the
official downstream KiCAD package.
Someone commented that teardrops are important for flexible PCBs. Maybe
sharp angles also affect flex pcbs?
And may be useful for people etching at home?
As a hobbyist sending boards to be made at the cheapest fab I can find,
it'd be nice not to have sharp angles just so
I don't have to think about
Hi,
I guess the other question is, do we even *want* to be doing this check?
It's not the 1980s anymore.
At the very least it should be able to be disabled for those of us who
aren't working with a PCB shop stuck in last century.
https://resources.ema-eda.com/blog/are-acid-traps-still-a-problem-
Hi Tom,
Thanks for the suggestion - that sounds like a fun problem. But I just
started working on named groups (after an email exchange with Seth).
Cheers,
Josh
On Mon, Jul 20, 2020 at 11:29 AM Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:
> On 18/07/2020 23:47, Joshua Redstone wrote:
>
On 18/07/2020 23:47, Joshua Redstone wrote:
> Thanks, that link's a helpful starting point.
> Josh
Hi Joshua,
If you could figure out the algorithm for robust acute angle detection
(your input is a set of BOARD_ITEMs), I can integrate it with the new
KiCad DRC engine.
Tom
>
> On Fri, Jul 17,
Neat, that'll be super useful
On Mon, Jul 20, 2020, 9:56 AM Jeff Young wrote:
> To do syntax highlighting and code completion.
>
> > On 20 Jul 2020, at 14:41, Ben Ellis wrote:
> >
> > Why are the DRC rules parsed w/ s-exprs as they're being typed instead
> of after? I just fixed a bug where typ
To do syntax highlighting and code completion.
> On 20 Jul 2020, at 14:41, Ben Ellis wrote:
>
> Why are the DRC rules parsed w/ s-exprs as they're being typed instead of
> after? I just fixed a bug where typing ) without ( crashed the entire program
> ___
Why are the DRC rules parsed w/ s-exprs as they're being typed instead of
after? I just fixed a bug where typing ) without ( crashed the entire
program
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpa
20 matches
Mail list logo
