Build from source MSYS2 the Easy Way Fails

[Brian Piccioni]

As per the title, after numerous attempts, this fails on Windows 10.

I completely installed Msys2 and made sure there were no other instances.

$ makepkg-mingw -is

runs for several minutes and fails with

"CMake Error at CMakeLists.txt:577 (find_package):
  By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "OCE", but
  CMake did not find one.

  Could not find a package configuration file provided by "OCE" (requested
  version 0.16) with any of the following names:

    OCEConfig.cmake
    oce-config.cmake

  Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
  to a directory containing one of the above files. If "OCE" provides a
  separate development package or SDK, be sure it has been installed."

Initially these files were not in my computer. I went to the directory
mingw-w64-oce
and there were only 3 files: oce-i686.install, oce-x86_64.install, and PKGBUILD. The only one I could figure out what to do with was PKGBUILD, so I ran

$ makepkg-mingw -is

within mingw-w64.

This ran for several hours. It gave me errors

"-- Configuring done
CMake Warning in adm/cmake/TKGeomAlgo/CMakeLists.txt:
  The object file directory

    C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-OCE-0.17.2/build-x86_64-w64-mingw32/adm/cmake/TKGeomAlgo/CMakeFiles/TKGeomAlgo.dir/

  has 145 characters. The maximum full path to an object file is 250
  characters (see CMAKE_OBJECT_PATH_MAX). Object file

    __/__/__/drv/Geom2dInt/Geom2dInt_SequenceNodeOfSeqPCOfPCLocFOfTheLocateExtPCOfTheProjPCurOfGInter_0.cxx.obj

  cannot be safely placed under this directory. The build may not work
  correctly.

CMake Warning in adm/cmake/TKSTEPBase/CMakeLists.txt:
  The object file directory

    C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-OCE-0.17.2/build-x86_64-w64-mingw32/adm/cmake/TKSTEPBase/CMakeFiles/TKSTEPBase.dir/

  has 145 characters. The maximum full path to an object file is 250
  characters (see CMAKE_OBJECT_PATH_MAX). Object file

    __/__/__/src/RWStepGeom/RWStepGeom_RWGeometricRepresentationContextAndParametricRepresentationContext.cxx.obj

  cannot be safely placed under this directory. The build may not work
  correctly.

-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS"

Sure enough the build of OCE failed at 78%
"[ 78%] Built target TKSTEPBase
make: *** [Makefile:163: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting..."

However, I found OCE-Config.cmake so set

$ set OCE_DIR=./BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-OCE-0.17.2/build-x86_64-w64-mingw32/OCEConfig.cmake

I tried to make Kicad again as per the instructions and got the same error.

I am pretty much stuck here: I followed the instructions at http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#msys2_easy exactly and the make fails.

Any advice/suggestions would be appreciated.

[Brian Piccioni (br0an)]

I did a complete new Msys2 installation. I noted that the link in the "easy way" instructions is obsolete (2015) so I went to msys2 and used their installer.

I did this

pacman -Syuu several times until there were no more updates

pacman -S base-devel git
pacman -S mingw-w64-x86_64-oce //At the suggestion of craftyjon of kicad forums

mkdir src
cd src
git clone https://github.com/Alexpux/MINGW-packages
cd MinGW-packages/mingw-w64-kicad-git

modify C:\msys64\etc\profile to include
OCE_DIR='/mingw64/lib/oce/'

makepkg-mingw -is

Again the system ran for several hours and failed exactly the same way, despite the fact I can, indeed, find the files

$ find $OCE_DIR -name "OCE*.cmake"
/mingw64/lib/oce/OCE-libraries-release.cmake
/mingw64/lib/oce/OCE-libraries.cmake
/mingw64/lib/oce/OCEConfig.cmake
/mingw64/lib/oce/OCEConfigVersion.cmake

I did notice that the compile actually had errors (see attachment).

It seems highly likely that the Kicad make instructions for windows are obsolete and/or there is an issue with the packages.

[Jon Evans (craftyjon)]

I'm going to try on my Win 10 VM this week and see if I can figure it out.

[Wayne Stambaugh (stambaughw)]

I did notice oce is not installed by default since we made the decision
to turn on all of the build options. I can update the PKGBUILD file to
fix that but there may be other issues at play due to changes in msys2.

On 3/6/2018 1:22 PM, Jon Evans wrote:
> I'm going to try on my Win 10 VM this week and see if I can figure it
> out.
>

[Brian Piccioni (br0an)]

I appreciate any help I can get on this. I am trying to build from source because I want to make a version of PCBNew with my RenumKiCadPCB function built in as a tool.

RenumKiCadPCB renumbers reference designations on the PCB geographically and back-annotates the schematic and netlist.

If I can accomplish that, despite my limited knowledge of c++, perhaps I can demonstrate it is a worthy function.

But if I can't build KiCad I can't get started. I'd prefer to not have to work in Linux because I'd have to install the OS and do most of my work in Windows anyway.

[Jon Evans (craftyjon)]

Okay, so Wayne just updated the manual build instructions but I noticed one issue, there appears to not be a package called mingw-w64-x86_64-ngspice in the registry. To get around this, I just built it from source using Alexpux's recipe.

I then discovered that the current OCE package contains a hard-coded path that causes the kicad build to fail (see: https://github.com/Alexpux/MINGW-packages/issues/1870 where the issue is fixed, but a fixed package doesn't seem to be available in the repo yet), so I also manually built that from source to work around the issue. In order to avoid the long path issue that Brian ran in to, I made my path as short as possible to the mingw packages repository ("/c/code/mwp")

Then I ran into this error while trying to build OCE:

g++.exe: error: CreateProcess: No such file or directory
g++.exe: error: CreateProcess: No such file or directory
make[2]: *** [adm/cmake/TKPCAF/CMakeFiles/TKPCAF.dir/build.make:64: adm/cmake/TKPCAF/CMakeFiles/TKPCAF.dir/__/__/__/src/PDataXtd/PDataXtd_Axis.cxx.obj] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [adm/cmake/TKPCAF/CMakeFiles/TKPCAF.dir/build.make:89: adm/cmake/TKPCAF/CMakeFiles/TKPCAF.dir/__/__/__/src/PDataXtd/PDataXtd_Constraint.cxx.obj] Error 1
g++.exe: error: CreateProcess: No such file or directory
make[2]: *** [adm/cmake/TKPCAF/CMakeFiles/TKPCAF.dir/build.make:114: adm/cmake/TKPCAF/CMakeFiles/TKPCAF.dir/__/__/__/src/PDataXtd/PDataXtd_Geometry.cxx.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:3391: adm/cmake/TKPCAF/CMakeFiles/TKPCAF.dir/all] Error 2

So, here's the steps I followed, after installing a fresh msys2 64-bit.
(assuming I have kicad already cloned into /c/code/kicad)

cd /c/code

pacman -S base-devel \
          git \
          mingw-w64-x86_64-cmake \
          mingw-w64-x86_64-doxygen \
          mingw-w64-x86_64-gcc \
          mingw-w64-x86_64-python2 \
          mingw-w64-x86_64-pkg-config \
          mingw-w64-x86_64-swig \
          mingw-w64-x86_64-boost \
          mingw-w64-x86_64-cairo \
          mingw-w64-x86_64-glew \
          mingw-w64-x86_64-curl \
          mingw-w64-x86_64-wxPython \
          mingw-w64-x86_64-wxWidgets \
          mingw-w64-x86_64-toolchain \
          mingw-w64-x86_64-glm

git clone https://github.com/Alexpux/MINGW-packages mwp
cd mwp/mingw-w64-ngspice
makepkg-mingw -is

<wait a while>

cd ../mingw-w64-oce
makepkg-mingw -is

<wait a while>
<after the build, pacman will install the resulting package (it will prompt you)>
<it will also then start building 32-bit after it builds 64-bit, but I killed it here to save time, since we only need 64-bit library to build 64-bit kicad.>

cd ../../kicad
mkdir -p build/debug
cd build/debug
cmake -DCMAKE_BUILD_TYPE=Debug \
      -G "MSYS Makefiles" \
      -DCMAKE_PREFIX_PATH=/mingw64 \
      -DCMAKE_INSTALL_PREFIX=/mingw64 \
      -DDEFAULT_INSTALL_PATH=/mingw64 \
      ../../
make -j4 install

<wait a while>

Now with oce and ngspice library issues fixed, KiCad successfully builds and installs to /mingw64/bin/

Morals of the story:
1) your disk path to sources for the mingw oce/ngspice libraries should be as short as possible
2) no one is regularly testing th...

[Jon Evans (craftyjon)]

Oops, I failed at editing my comment before posting -- the OCE compile issue I listed is a symptom of having too long a path. What I meant to say is that before I shortened the path to "/c/code/mwp", this is the kind of issue I got

[Brian Piccioni (br0an)]

Wow! Thanks so much for your help/effort!

I will try the new build instructions you have posted. I hope I can follow them.

Yes, I figured nobody was checking the build instructions. Some of them are clearly out of date. Same goes for Kicad-winbuilder as well, which I find odd.

Clearly KiCad is mostly a Linux club but that is impractical for me as I work at home and tend to do my hobbies in between moments of inspiration. All my work work is Windows based.

[Brian Piccioni (br0an)]

FYI the build instructions at http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#msys2_easy sill point to 2015 Msys2 installers.

[jean-pierre charras (jp-charras)]

"Clearly KiCad is mostly a Linux club"

You are absolutely wrong.
But it is multi-platform, and this means it creates constraints for development tools.

[Wayne Stambaugh (stambaughw)]

On 3/7/2018 9:27 AM, Brian Piccioni wrote:
> Wow! Thanks so much for your help/effort!
>
> I will try the new build instructions you have posted. I hope I can
> follow them.
>
> Yes, I figured nobody was checking the build instructions. Some of them
> are clearly out of date. Same goes for Kicad-winbuilder as well, which I
> find odd.
>
> Clearly KiCad is mostly a Linux club but that is impractical for me as I
> work at home and tend to do my hobbies in between moments of
> inspiration. All my work work is Windows based.
>

I use windows for at least half of my development. Issues occasionally
pop up but they are fairly uncommon. The problem is that windows is a
terrible development platform made tolerable by projects like msys2.
The kicad and msys2 projects change very quickly so keeping the windows
build instructions up to date is not easy so you will have to do some
leg work on your own to build kicad on windows. The other option is to
turn off the oce plugin and spice simulation so you don't have to build
the oce and ngspice packages from source. I guess the msys2 folks never
got around to providing packages for oce and ngspice or they removed
them from the archive. It's been a while so I don't remember how I
ended up with these packages on my systems. Most likely I built them
from source assuming that the msys2 project would provide binary
packages for them.

Are your planning on hacking on kicad? If not, please consider using a
nightly build rather than building from source.

[Brian Piccioni (br0an)]

"You are absolutely wrong.
But it is multi-platform, and this means it creates constraints for development tools."

I wasn't being critical, however, the fact the Windows build instructions are years out of date and I seem to be the first one to notice this suggests that few people build it on Windows, or if they do they are not doing it from scratch using the instructions.

Or, perhaps they gave up and didn't report it.

If not for the fact my work patterns are pinned to Windows I would have given up and tried a Linux build.

[Brian Piccioni (br0an)]

Wayne

(For some reason your reply is not on the bug website)

I don't know how to hack the build process to remove the offending issues. If I did I would have posted a fix rather than a bug.

My plan is this: I wrote a c-utility RenumKiCadPCB which provides geographic renumbering of the PCB with full back-annotation to the schematics and netlist. It recurses the schematic hierarchy completely. Other applications I tried prior to writing Renum either flat out failed, only worked in simple cases (i.e. no hierarchy), or had other major issues.

I wrote this for me, posted it online, and have received positive feedback from its users. Because it was written as a command line program its user base is probably much less than would otherwise have been the case.

Since this function is absent from PCBNew (though present in every other PCB CAD tool I've used) I thought it would make a good addition to the code base.

I am pretty sure somebody who knows their way around KiCad could easily incorporate it into PCBNew so I proposed it and got no takers. I was also informed the feature set was already frozen (even though the most recent nightly build changed the menu bar on me).

So, I figure if I can build KiCad I can:
1) learn something about a complex project;
2) learn more about c++;
3) learn how a gui is coded;
4) if I am lucky, follow the instructions here http://docs.kicad-pcb.org/doxygen/md_Documentation_development_tool-framework.html#tutorial which will allow me to make a version of PCBNew with Renum built in.

If I accomplish 3 then perhaps it would be easier to the devs to consider incorporate this missing function into PCBNew in the future.

If nothing else I would have learned something.

Regardless, there is no point in having documentation which provides step by step build instructions if those instructions fail.

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Wayne Stambaugh
Sent: March 7, 2018 10:19 AM
To: <email address hidden>
Subject: Re: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

On 3/7/2018 9:27 AM, Brian Piccioni wrote:
> Wow! Thanks so much for your help/effort!
>
> I will try the new build instructions you have posted. I hope I can
> follow them.
>
> Yes, I figured nobody was checking the build instructions. Some of
> them are clearly out of date. Same goes for Kicad-winbuilder as well,
> which I find odd.
>
> Clearly KiCad is mostly a Linux club but that is impractical for me as
> I work at home and tend to do my hobbies in between moments of
> inspiration. All my work work is Windows based.
>

I use windows for at least half of my development. Issues occasionally pop up but they are fairly uncommon. The problem is that windows is a terrible development platform made tolerable by projects like msys2.
The kicad and msys2 projects change very quickly so keeping the windows build instructions up to date is not easy so you will have to do some leg work on your own to build kicad on windows. The other option is to turn off the oce plugin and spice simulation so you don't have to build the oce and ngspice packages from source. I guess the msy...

[Jon Evans (craftyjon)]

Hi Brian,

I think your feature is a good idea and it would be great if you got involved in KiCad development. We are just now thinking about the roadmap for V6.0 and beyond, since 5.0 is so close to release.

Back-annotation including geographic refdes updating was already proposed as a thing that we want to have in the future (but I don't think anyone other than you has worked on it). It might be good for you to talk with Orson and Tom about your plans and coordinate, since I think they have thought about it some already, and back-annotation covers a number of features (like pin/part swapping) in addition to updating refdes based on location on the board.

Feel free to reach out to me by email or on the forums (username craftyjon) if you want tips as you get involved with modifying the KiCad code.

[Brian Piccioni (br0an)]

By the way: just to be clear, I deeply appreciate your efforts and those of the Kicad team.

I know that maintenance can be a pain and I understand that Msys is the way to go on Windows for cross-platform work.

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Wayne Stambaugh
Sent: March 7, 2018 10:19 AM
To: <email address hidden>
Subject: Re: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

On 3/7/2018 9:27 AM, Brian Piccioni wrote:
> Wow! Thanks so much for your help/effort!
>
> I will try the new build instructions you have posted. I hope I can
> follow them.
>
> Yes, I figured nobody was checking the build instructions. Some of
> them are clearly out of date. Same goes for Kicad-winbuilder as well,
> which I find odd.
>
> Clearly KiCad is mostly a Linux club but that is impractical for me as
> I work at home and tend to do my hobbies in between moments of
> inspiration. All my work work is Windows based.
>

I use windows for at least half of my development. Issues occasionally pop up but they are fairly uncommon. The problem is that windows is a terrible development platform made tolerable by projects like msys2.
The kicad and msys2 projects change very quickly so keeping the windows build instructions up to date is not easy so you will have to do some leg work on your own to build kicad on windows. The other option is to turn off the oce plugin and spice simulation so you don't have to build the oce and ngspice packages from source. I guess the msys2 folks never got around to providing packages for oce and ngspice or they removed them from the archive. It's been a while so I don't remember how I ended up with these packages on my systems. Most likely I built them from source assuming that the msys2 project would provide binary packages for them.

Are your planning on hacking on kicad? If not, please consider using a nightly build rather than building from source.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  New

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

  $ makepkg-mingw -is

  runs for several minutes and fails with

  "CMake Error at CMakeLists.txt:577 (find_package):
    By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
    asked CMake to find a package configuration file provided by "OCE", but
    CMake did not find one.

    Could not find a package configuration file provided by "OCE" (requested
    version 0.16) with any of the following names:

      OCEConfig.cmake
      oce-config.cmake

    Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
    to a directory containing one of the above files. If "OCE" provides a
    separate development package or SDK, be sure it has been installed."

  Initially these files were not in my computer. I went to the directory
  mingw-w64-oce
  and there were only 3 files: oce-i686.install, oce-x86_64...

[Brian Piccioni (br0an)]

Thank you so much for the encouragement, Jon!

I would like to prep myself a bit (hence the windows build) to see is I am up to it and I'd like to get my code up to scratch as I haven't worked in software development for decades and mostly worked on microcontrollers.

I have weird relationship with software: occasionally I become obsessed with a project and become very productive but my methods, etc., are decades out of date.

I will indeed reach out to you once I get past these hurdles. I believe I can contribute once I get past that.

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Jon Evans
Sent: March 7, 2018 11:17 AM
To: <email address hidden>
Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

Hi Brian,

I think your feature is a good idea and it would be great if you got involved in KiCad development. We are just now thinking about the roadmap for V6.0 and beyond, since 5.0 is so close to release.

Back-annotation including geographic refdes updating was already proposed as a thing that we want to have in the future (but I don't think anyone other than you has worked on it). It might be good for you to talk with Orson and Tom about your plans and coordinate, since I think they have thought about it some already, and back-annotation covers a number of features (like pin/part swapping) in addition to updating refdes based on location on the board.

Feel free to reach out to me by email or on the forums (username
craftyjon) if you want tips as you get involved with modifying the KiCad code.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  New

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

  $ makepkg-mingw -is

  runs for several minutes and fails with

  "CMake Error at CMakeLists.txt:577 (find_package):
    By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
    asked CMake to find a package configuration file provided by "OCE", but
    CMake did not find one.

    Could not find a package configuration file provided by "OCE" (requested
    version 0.16) with any of the following names:

      OCEConfig.cmake
      oce-config.cmake

    Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
    to a directory containing one of the above files. If "OCE" provides a
    separate development package or SDK, be sure it has been installed."

  Initially these files were not in my computer. I went to the directory
  mingw-w64-oce
  and there were only 3 files: oce-i686.install, oce-x86_64.install, and PKGBUILD. The only one I could figure out what to do with was PKGBUILD, so I ran

  $ makepkg-mingw -is

  within mingw-w64.

  This ran for several hours. It gave me errors

  "-- Configuring done
  CMake Warning in adm/cmake/TKGeomAlgo/CMakeLists.txt:
    The object file directory

      C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-
  OCE-0.17...

[Wayne Stambaugh (stambaughw)]

@Brian,

I think your back-annotation tool would be a useful tool for users. As
Jon mentioned. Please keep in mind back annotation for pin and gate
swapping in being planned for v6. I'm sure this will dovetail in with
the work that you are doing so it is important to communicate with the
development team what you are working on to prevent duplication of
effort and merge conflicts. I cannot stress this enough. We have had
too many developers write large pieces of code that could not be used
because it didn't fit into what other developers were working on. That
is why we have a road map. You should look there first. As always, if
you are not sure, ask.

As for msys2 build issues. I was incorrect about oce and ngspice not
being packaged. They actually are packaged and can be installed using
pacman. Will try to do a better job of keeping the windows build
instructions up to date. FYI, there is a known issue (see the link Jon
provided) in 32-bit builds so I recommend you use 64-bit (x86_64) builds
of kicad or you will have to fix a broken path in some of the build.make
files in your kicad binary path. Since it sounds like you are going to
be hacking on kicad, I would avoid building and installing a binary
package. There is no need to install the libraries and docs everytime
you want to make a change and rebuild kicad. Building kicad itself
takes long enough on windows. The overhead of the libraries will make
this process really painful.

Cheers,

Wayne

On 3/7/2018 11:05 AM, Brian Piccioni wrote:
> Wayne
>
> (For some reason your reply is not on the bug website)
>
> I don't know how to hack the build process to remove the offending
> issues. If I did I would have posted a fix rather than a bug.
>
> My plan is this: I wrote a c-utility RenumKiCadPCB which provides
> geographic renumbering of the PCB with full back-annotation to the
> schematics and netlist. It recurses the schematic hierarchy completely.
> Other applications I tried prior to writing Renum either flat out
> failed, only worked in simple cases (i.e. no hierarchy), or had other
> major issues.
>
> I wrote this for me, posted it online, and have received positive
> feedback from its users. Because it was written as a command line
> program its user base is probably much less than would otherwise have
> been the case.
>
> Since this function is absent from PCBNew (though present in every other
> PCB CAD tool I've used) I thought it would make a good addition to the
> code base.
>
> I am pretty sure somebody who knows their way around KiCad could easily
> incorporate it into PCBNew so I proposed it and got no takers. I was
> also informed the feature set was already frozen (even though the most
> recent nightly build changed the menu bar on me).
>
> So, I figure if I can build KiCad I can:
> 1) learn something about a complex project;
> 2) learn more about c++;
> 3) learn how a gui is coded;
> 4) if I am lucky, follow the instructions here http://docs.kicad-pcb.org/doxygen/md_Documentation_development_tool-framework.html#tutorial which will allow me to make a version of PCBNew with Renum built in.
>
> If I accomplish 3 then perhaps it would be easier to the devs ...

[Brian Piccioni (br0an)]

Wayne

Thanks for the encouragement. My hope is that at least if I can build and trivially modify KiCad interaction with developers will be more productive for them, especially given my modest expertise. Similarly, it will be easier for me to follow the road map if I have a clue to begin with.

Renumbering has three major components: parsing the PCB and schematics (not as trivial as you'd imagine given the potential for a hierarchy), creating a change plan, and implementing that change plan on the respective files (PCB, schematics, and netlist), basically back-annotation. I suspect that whatever changes are made to the file structures to enable pin-swapping will most like impact the third component, namely back-annotation.

I did make a "feature request" and was hopeful somebody would reach out to me. When that didn't happen I figured I'd move it along myself a bit farther.

That said, I'm not trying to wag the dog. I'm sure the devs are very competent and I don't want to waste their time because I know what it is like to have to deal with a complete newb like me asking questions all the time. That said I will review the roadmap.

I am exclusively using msys64 but the build seems to combine both, though I'm not sure why. My skills on things like cmake are negligible so I am very hesitant to try and parse it.

I do not understand what this means

" I would avoid building and installing a binary package. There is no need to install the libraries and docs everytime you want to make a change and rebuild kicad. Building kicad itself takes long enough on windows. The overhead of the libraries will make this process really painful."

Except to say that yes, I'd very much like to know how to build *only* PCBnew, at least for the moment. I just don't have a clue how to start.

Since I only found instructions on how to build all of Kicad I figured I'd start with that. Once I did that I could pare it down. If there is a shortcut to only building PCBnew I'd be deliriously happy.

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Wayne Stambaugh
Sent: March 7, 2018 1:03 PM
To: <email address hidden>
Subject: Re: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

@Brian,

I think your back-annotation tool would be a useful tool for users. As Jon mentioned. Please keep in mind back annotation for pin and gate swapping in being planned for v6. I'm sure this will dovetail in with the work that you are doing so it is important to communicate with the development team what you are working on to prevent duplication of effort and merge conflicts. I cannot stress this enough. We have had too many developers write large pieces of code that could not be used because it didn't fit into what other developers were working on. That is why we have a road map. You should look there first. As always, if you are not sure, ask.

As for msys2 build issues. I was incorrect about oce and ngspice not being packaged. They actually are packaged and can be installed using pacman. Will try to do a better job of keeping the windows build instructions up to date. FYI, there is a known issue (see the link Jon
pr...

[Jon Evans (craftyjon)]

I've made some tweaks to the build documentation based on my testing.

[Brian Piccioni (br0an)]

Thanks!

I'll give it a try as soon as I can.

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Jon Evans
Sent: March 7, 2018 9:07 PM
To: <email address hidden>
Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

I've made some tweaks to the build documentation based on my testing.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  New

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

To manage notifications about this bug go to:
https://bugs.launchpad.net/kicad/+bug/1752150/+subscriptions

[Wayne Stambaugh (stambaughw)]

@Brian,

On 03/07/2018 01:36 PM, Brian Piccioni wrote:
> Wayne
>
> Thanks for the encouragement. My hope is that at least if I can build
> and trivially modify KiCad interaction with developers will be more
> productive for them, especially given my modest expertise. Similarly, it
> will be easier for me to follow the road map if I have a clue to begin
> with.
>
> Renumbering has three major components: parsing the PCB and schematics
> (not as trivial as you'd imagine given the potential for a hierarchy),
> creating a change plan, and implementing that change plan on the
> respective files (PCB, schematics, and netlist), basically back-
> annotation. I suspect that whatever changes are made to the file
> structures to enable pin-swapping will most like impact the third
> component, namely back-annotation.
>
> I did make a "feature request" and was hopeful somebody would reach out
> to me. When that didn't happen I figured I'd move it along myself a bit
> farther.
>
> That said, I'm not trying to wag the dog. I'm sure the devs are very
> competent and I don't want to waste their time because I know what it is
> like to have to deal with a complete newb like me asking questions all
> the time. That said I will review the roadmap.
>
> I am exclusively using msys64 but the build seems to combine both,
> though I'm not sure why. My skills on things like cmake are negligible
> so I am very hesitant to try and parse it.
>
> I do not understand what this means
>
> " I would avoid building and installing a binary package. There is no
> need to install the libraries and docs everytime you want to make a
> change and rebuild kicad. Building kicad itself takes long enough on
> windows. The overhead of the libraries will make this process really
> painful."

It means use the hard way instructions instead of the easy way
instructions so you only build kicad and not repackage all of the
libraries and documentation every time you make a change to the kicad
source.

>
> Except to say that yes, I'd very much like to know how to build *only*
> PCBnew, at least for the moment. I just don't have a clue how to start.

Run `make pcbnew` instead of `make`. This will only build pcbnew and
it's build dependencies.

>
> Since I only found instructions on how to build all of Kicad I figured
> I'd start with that. Once I did that I could pare it down. If there is a
> shortcut to only building PCBnew I'd be deliriously happy.
>
> -----Original Message-----
> From: <email address hidden> <email address hidden> On Behalf Of Wayne Stambaugh
> Sent: March 7, 2018 1:03 PM
> To: <email address hidden>
> Subject: Re: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails
>
> @Brian,
>
> I think your back-annotation tool would be a useful tool for users. As
> Jon mentioned. Please keep in mind back annotation for pin and gate
> swapping in being planned for v6. I'm sure this will dovetail in with
> the work that you are doing so it is important to communicate with the
> development team what you are working on to prevent duplication of
> effort and merge conflicts. I cannot stress this enough. We have had
> too many developers write large pieces of...

[Brian Piccioni (br0an)]

Thanks!

make pcbnew in the \src\MINGW-packages\mingw-w64-kicad-git\src\build-x86_64-w64-mingw32\pcbnew worked and built a functioning pcbnew!

I had tried make or make -all but those builds failed about 50% through. I obviously don't know enough about make.

This is great help!

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Wayne Stambaugh
Sent: March 10, 2018 8:20 AM
To: <email address hidden>
Subject: Re: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

@Brian,

On 03/07/2018 01:36 PM, Brian Piccioni wrote:
> Wayne
>
> Thanks for the encouragement. My hope is that at least if I can build
> and trivially modify KiCad interaction with developers will be more
> productive for them, especially given my modest expertise. Similarly,
> it will be easier for me to follow the road map if I have a clue to
> begin with.
>
> Renumbering has three major components: parsing the PCB and schematics
> (not as trivial as you'd imagine given the potential for a hierarchy),
> creating a change plan, and implementing that change plan on the
> respective files (PCB, schematics, and netlist), basically back-
> annotation. I suspect that whatever changes are made to the file
> structures to enable pin-swapping will most like impact the third
> component, namely back-annotation.
>
> I did make a "feature request" and was hopeful somebody would reach
> out to me. When that didn't happen I figured I'd move it along myself
> a bit farther.
>
> That said, I'm not trying to wag the dog. I'm sure the devs are very
> competent and I don't want to waste their time because I know what it
> is like to have to deal with a complete newb like me asking questions
> all the time. That said I will review the roadmap.
>
> I am exclusively using msys64 but the build seems to combine both,
> though I'm not sure why. My skills on things like cmake are negligible
> so I am very hesitant to try and parse it.
>
> I do not understand what this means
>
> " I would avoid building and installing a binary package. There is no
> need to install the libraries and docs everytime you want to make a
> change and rebuild kicad. Building kicad itself takes long enough on
> windows. The overhead of the libraries will make this process really
> painful."

It means use the hard way instructions instead of the easy way instructions so you only build kicad and not repackage all of the libraries and documentation every time you make a change to the kicad source.

>
> Except to say that yes, I'd very much like to know how to build *only*
> PCBnew, at least for the moment. I just don't have a clue how to start.

Run `make pcbnew` instead of `make`. This will only build pcbnew and it's build dependencies.

>
> Since I only found instructions on how to build all of Kicad I figured
> I'd start with that. Once I did that I could pare it down. If there is
> a shortcut to only building PCBnew I'd be deliriously happy.
>

[Brian Piccioni (br0an)]

Jon

I've managed to build PCBNew and figure I should be able to incorporate PCB renumbering into the source.

I cannot figure out how to access the code documentation: I end up on dead links whenever I try and its kid of hard given the fact that most searches lead to user documentation.

I would like and work with the developers to add renumbering to V6. I realize I will have to rewrite a significant portion of the code but the "hard part" should be able to stay the same.

If you can help get me started I would appreciate it. There are some things I will need to understand with respect to the general direction of file formats, etc., so as not to waste too much effort.

In the meantime I am trying to track down one last bug and will put my code into line with the KiCad coding standards.

Thanks in advance,

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Jon Evans
Sent: March 7, 2018 11:17 AM
To: <email address hidden>
Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

Hi Brian,

I think your feature is a good idea and it would be great if you got involved in KiCad development. We are just now thinking about the roadmap for V6.0 and beyond, since 5.0 is so close to release.

Back-annotation including geographic refdes updating was already proposed as a thing that we want to have in the future (but I don't think anyone other than you has worked on it). It might be good for you to talk with Orson and Tom about your plans and coordinate, since I think they have thought about it some already, and back-annotation covers a number of features (like pin/part swapping) in addition to updating refdes based on location on the board.

Feel free to reach out to me by email or on the forums (username
craftyjon) if you want tips as you get involved with modifying the KiCad code.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  New

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

  $ makepkg-mingw -is

  runs for several minutes and fails with

  "CMake Error at CMakeLists.txt:577 (find_package):
    By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
    asked CMake to find a package configuration file provided by "OCE", but
    CMake did not find one.

    Could not find a package configuration file provided by "OCE" (requested
    version 0.16) with any of the following names:

      OCEConfig.cmake
      oce-config.cmake

    Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
    to a directory containing one of the above files. If "OCE" provides a
    separate development package or SDK, be sure it has been installed."

  Initially these files were not in my computer. I went to the directory
  mingw-w64-oce
  and there were only 3 files: oce-i686.install, oce-x86_64.install, and PKGBUILD. The only one I could figure out what to do with was PKGBUILD, so I ran

  $ ...

[Nick Østergaard (nickoe)]

Hi Brian,

If you have trouble with the local devdocs, you may just use the ones online at http://docs.kicad-pcb.org/doxygen/annotated.html They should be up to date with the master branch.

If you are the kind of guy for IRC, that is also an option if you want some more interactive help :)

[Wayne Stambaugh (stambaughw)]

Assuming you have doxygen installed, did you run `make doxygne-docs`?
The result of this will be in Documentation/doxygen/html. Use your web
browser to open the index.html file. If you don't want to bother
building the source documentation you can always view the nightly build
available on the kicad website.

On 3/15/2018 3:20 PM, Brian Piccioni wrote:
> Jon
>
> I've managed to build PCBNew and figure I should be able to incorporate
> PCB renumbering into the source.
>
> I cannot figure out how to access the code documentation: I end up on
> dead links whenever I try and its kid of hard given the fact that most
> searches lead to user documentation.
>
> I would like and work with the developers to add renumbering to V6. I
> realize I will have to rewrite a significant portion of the code but the
> "hard part" should be able to stay the same.
>
> If you can help get me started I would appreciate it. There are some
> things I will need to understand with respect to the general direction
> of file formats, etc., so as not to waste too much effort.
>
> In the meantime I am trying to track down one last bug and will put my
> code into line with the KiCad coding standards.
>
> Thanks in advance,
>
> Brian
>
> -----Original Message-----
> From: <email address hidden> <email address hidden> On Behalf Of Jon Evans
> Sent: March 7, 2018 11:17 AM
> To: <email address hidden>
> Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails
>
> Hi Brian,
>
> I think your feature is a good idea and it would be great if you got
> involved in KiCad development. We are just now thinking about the
> roadmap for V6.0 and beyond, since 5.0 is so close to release.
>
> Back-annotation including geographic refdes updating was already
> proposed as a thing that we want to have in the future (but I don't
> think anyone other than you has worked on it). It might be good for you
> to talk with Orson and Tom about your plans and coordinate, since I
> think they have thought about it some already, and back-annotation
> covers a number of features (like pin/part swapping) in addition to
> updating refdes based on location on the board.
>
> Feel free to reach out to me by email or on the forums (username
> craftyjon) if you want tips as you get involved with modifying the KiCad code.
>
> --
> You received this bug notification because you are subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1752150
>
> Title:
> Build from source MSYS2 the Easy Way Fails
>
> Status in KiCad:
> New
>
> Bug description:
> As per the title, after numerous attempts, this fails on Windows 10.
>
> I completely installed Msys2 and made sure there were no other
> instances.
>
> $ makepkg-mingw -is
>
> runs for several minutes and fails with
>
> "CMake Error at CMakeLists.txt:577 (find_package):
> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
> asked CMake to find a package configuration file provided by "OCE", but
> CMake did not find one.
>
> Could not find a package configuration file provided by "OCE" (requested
> version 0.16) with any of the following names:
>
> OCEConfig.cma...

[Brian Piccioni (br0an)]

Nick

Thanks for the link. I had searched the web numerous times and only found user documentation. I'll see what I can make of this. I did manage to compile/run PCBNew and move it into my development platform, which was my objective.

I have very little knowledge of c++ (I am an old guy and a hardware guy and most of my development has been low level).

Nonetheless I would like to volunteer to port my PCB renumbering code into KiCad. I had a look at PCBNew and I am pretty sure it would be something I can do in collaboration with the development team as it is a feature which is missing from Kicad and I've written the most challenging aspect of the code. The major work that is left would be to provide a UI (which I believe I can derive from the existing code) and replace code I wrote from scratch for thing like creating the schematic hierarchy with existing Kicad code.

I have never used IRC so I don't know how to proceed (when I said old, I meant old - plus there was a 30 year gap in my tech career).

Thanks

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Nick Østergaard
Sent: March 15, 2018 3:36 PM
To: <email address hidden>
Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

Hi Brian,

If you have trouble with the local devdocs, you may just use the ones online at http://docs.kicad-pcb.org/doxygen/annotated.html They should be up to date with the master branch.

If you are the kind of guy for IRC, that is also an option if you want some more interactive help :)

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  New

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

  $ makepkg-mingw -is

  runs for several minutes and fails with

  "CMake Error at CMakeLists.txt:577 (find_package):
    By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
    asked CMake to find a package configuration file provided by "OCE", but
    CMake did not find one.

    Could not find a package configuration file provided by "OCE" (requested
    version 0.16) with any of the following names:

      OCEConfig.cmake
      oce-config.cmake

    Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
    to a directory containing one of the above files. If "OCE" provides a
    separate development package or SDK, be sure it has been installed."

  Initially these files were not in my computer. I went to the directory
  mingw-w64-oce
  and there were only 3 files: oce-i686.install, oce-x86_64.install, and PKGBUILD. The only one I could figure out what to do with was PKGBUILD, so I ran

  $ makepkg-mingw -is

  within mingw-w64.

  This ran for several hours. It gave me errors

  "-- Configuring done
  CMake Warning in adm/cmake/TKGeomAlgo/CMakeLists.txt:
    The object file directory

      C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-
  OCE-0.17.2/build-
  x86_64-w64-mingw32/ad...

[Brian Piccioni (br0an)]

Wayne

I shall give that a try. I appreciate the help: a lot of this is new to me.

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Wayne Stambaugh
Sent: March 15, 2018 3:42 PM
To: <email address hidden>
Subject: Re: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

Assuming you have doxygen installed, did you run `make doxygne-docs`?
The result of this will be in Documentation/doxygen/html. Use your web browser to open the index.html file. If you don't want to bother building the source documentation you can always view the nightly build available on the kicad website.

On 3/15/2018 3:20 PM, Brian Piccioni wrote:
> Jon
>
> I've managed to build PCBNew and figure I should be able to
> incorporate PCB renumbering into the source.
>
> I cannot figure out how to access the code documentation: I end up on
> dead links whenever I try and its kid of hard given the fact that most
> searches lead to user documentation.
>
> I would like and work with the developers to add renumbering to V6. I
> realize I will have to rewrite a significant portion of the code but
> the "hard part" should be able to stay the same.
>
> If you can help get me started I would appreciate it. There are some
> things I will need to understand with respect to the general direction
> of file formats, etc., so as not to waste too much effort.
>
> In the meantime I am trying to track down one last bug and will put my
> code into line with the KiCad coding standards.
>
> Thanks in advance,
>
> Brian
>
> -----Original Message-----
> From: <email address hidden> <email address hidden> On Behalf Of Jon
> Evans
> Sent: March 7, 2018 11:17 AM
> To: <email address hidden>
> Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails
>
> Hi Brian,
>
> I think your feature is a good idea and it would be great if you got
> involved in KiCad development. We are just now thinking about the
> roadmap for V6.0 and beyond, since 5.0 is so close to release.
>
> Back-annotation including geographic refdes updating was already
> proposed as a thing that we want to have in the future (but I don't
> think anyone other than you has worked on it). It might be good for
> you to talk with Orson and Tom about your plans and coordinate, since
> I think they have thought about it some already, and back-annotation
> covers a number of features (like pin/part swapping) in addition to
> updating refdes based on location on the board.
>
> Feel free to reach out to me by email or on the forums (username
> craftyjon) if you want tips as you get involved with modifying the KiCad code.
>
> --
> You received this bug notification because you are subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1752150
>
> Title:
> Build from source MSYS2 the Easy Way Fails
>
> Status in KiCad:
> New
>
> Bug description:
> As per the title, after numerous attempts, this fails on Windows 10.
>
> I completely installed Msys2 and made sure there were no other
> instances.
>
> $ makepkg-mingw -is
>
> runs for several minutes and fails with
>
> "CMake Error at CMakeLists.txt:577 (fin...

[Paulo Alcobia (paulo-alcobia)]

Build from source MSYS2 the Easy Way Fails
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_windows

Hi,
I have been trying for a week to make this work in my win10-64 machine and I just reinstalled the latest stable version of Msys2 flowing the link in the page and flowed the instructions but unfortunately it still fails. The first bump on the road is that there is no msys2_shell.bat in my version of Msys2 the name has changed, then some dependencies fail to install/compile...

Are there any specific versions that work?

Is there any working image of the build environment available for download anywhere?

After spending about 25 hours trying to get this to work. I would like to be able to get it fixed. And if there is nothing out there, I would like to make my image available to anyone wanting to give Kicad a try developing something for the community and use their time coding instead of spending it setting up the tools.

thanks, I appreciate your help,
Paulo

[Nick Østergaard (nickoe)]

The main problem for me is that there have been issues upstream with MSYS2 to setup a proper environment automatically. This is what the kicad-winbuilder does, but it is currently broken, because MSYS2 is broken. You are likely to be able to make it work if you install manually, but if you don't know what you are doing, your chance of success is of course low. Also, if you are not able to differentiate between the msys2 shell and the mingw shell environments.

The bat files have been replaced by exe's in msys2 some time ago.

[Jon Evans (craftyjon)]

@Nick @Wayne maybe we should just remove the "Easy Way" from the KiCad docs for now, since it is broken? The "hard way" at least works if you know what you are doing.

[Wayne Stambaugh (stambaughw)]

@Jon, I'm not opposed to removing this section. I wrote it for users
who wanted a package to install using pacman rather than running `make
install`.

On 3/21/2018 9:40 AM, Jon Evans wrote:
> @Nick @Wayne maybe we should just remove the "Easy Way" from the KiCad
> docs for now, since it is broken? The "hard way" at least works if you
> know what you are doing.
>

[Jon Evans (craftyjon)]

OK, I removed the easy way and verified that the remaining instructions work for me on Windows 10
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_windows

[Brian Piccioni (br0an)]

I'm the guy who (I believe) pointed out the easy way didn't work. I'll give the new instructions a try.

I'll give it a try.

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Jon Evans
Sent: March 21, 2018 3:22 PM
To: <email address hidden>
Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

OK, I removed the easy way and verified that the remaining instructions work for me on Windows 10 http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_windows

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  New

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

  $ makepkg-mingw -is

  runs for several minutes and fails with

  "CMake Error at CMakeLists.txt:577 (find_package):
    By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
    asked CMake to find a package configuration file provided by "OCE", but
    CMake did not find one.

    Could not find a package configuration file provided by "OCE" (requested
    version 0.16) with any of the following names:

      OCEConfig.cmake
      oce-config.cmake

    Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
    to a directory containing one of the above files. If "OCE" provides a
    separate development package or SDK, be sure it has been installed."

  Initially these files were not in my computer. I went to the directory
  mingw-w64-oce
  and there were only 3 files: oce-i686.install, oce-x86_64.install, and PKGBUILD. The only one I could figure out what to do with was PKGBUILD, so I ran

  $ makepkg-mingw -is

  within mingw-w64.

  This ran for several hours. It gave me errors

  "-- Configuring done
  CMake Warning in adm/cmake/TKGeomAlgo/CMakeLists.txt:
    The object file directory

      C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-
  OCE-0.17.2/build-
  x86_64-w64-mingw32/adm/cmake/TKGeomAlgo/CMakeFiles/TKGeomAlgo.dir/

    has 145 characters. The maximum full path to an object file is 250
    characters (see CMAKE_OBJECT_PATH_MAX). Object file

  __/__/__/drv/Geom2dInt/Geom2dInt_SequenceNodeOfSeqPCOfPCLocFOfTheLocateExtPCOfTheProjPCurOfGInter_0.cxx.obj

    cannot be safely placed under this directory. The build may not work
    correctly.

  CMake Warning in adm/cmake/TKSTEPBase/CMakeLists.txt:
    The object file directory

      C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-
  OCE-0.17.2/build-
  x86_64-w64-mingw32/adm/cmake/TKSTEPBase/CMakeFiles/TKSTEPBase.dir/

    has 145 characters. The maximum full path to an object file is 250
    characters (see CMAKE_OBJECT_PATH_MAX). Object file

  __/__/__/src/RWStepGeom/RWStepGeom_RWGeometricRepresentationContextAndParametricRepresentationContext.cxx.obj

    cannot be safely placed under this directory. The build may not work
    correctly.

  -- Generating done
  CMake Warning:
    Ma...

[Brian Piccioni (br0an)]

Woohoo!

I followed the new instructions on a not new Msys2 installation and it worked (apparently)!

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Jon Evans
Sent: March 21, 2018 3:22 PM
To: <email address hidden>
Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

OK, I removed the easy way and verified that the remaining instructions work for me on Windows 10 http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_windows

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  New

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

  $ makepkg-mingw -is

  runs for several minutes and fails with

  "CMake Error at CMakeLists.txt:577 (find_package):
    By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
    asked CMake to find a package configuration file provided by "OCE", but
    CMake did not find one.

    Could not find a package configuration file provided by "OCE" (requested
    version 0.16) with any of the following names:

      OCEConfig.cmake
      oce-config.cmake

    Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
    to a directory containing one of the above files. If "OCE" provides a
    separate development package or SDK, be sure it has been installed."

  Initially these files were not in my computer. I went to the directory
  mingw-w64-oce
  and there were only 3 files: oce-i686.install, oce-x86_64.install, and PKGBUILD. The only one I could figure out what to do with was PKGBUILD, so I ran

  $ makepkg-mingw -is

  within mingw-w64.

  This ran for several hours. It gave me errors

  "-- Configuring done
  CMake Warning in adm/cmake/TKGeomAlgo/CMakeLists.txt:
    The object file directory

      C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-
  OCE-0.17.2/build-
  x86_64-w64-mingw32/adm/cmake/TKGeomAlgo/CMakeFiles/TKGeomAlgo.dir/

    has 145 characters. The maximum full path to an object file is 250
    characters (see CMAKE_OBJECT_PATH_MAX). Object file

  __/__/__/drv/Geom2dInt/Geom2dInt_SequenceNodeOfSeqPCOfPCLocFOfTheLocateExtPCOfTheProjPCurOfGInter_0.cxx.obj

    cannot be safely placed under this directory. The build may not work
    correctly.

  CMake Warning in adm/cmake/TKSTEPBase/CMakeLists.txt:
    The object file directory

      C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-
  OCE-0.17.2/build-
  x86_64-w64-mingw32/adm/cmake/TKSTEPBase/CMakeFiles/TKSTEPBase.dir/

    has 145 characters. The maximum full path to an object file is 250
    characters (see CMAKE_OBJECT_PATH_MAX). Object file

  __/__/__/src/RWStepGeom/RWStepGeom_RWGeometricRepresentationContextAndParametricRepresentationContext.cxx.obj

    cannot be safely placed under this directory. The build may not work
    correctly.

  -- Generating done
  CMake Warning:
    Manually-specified variable...

[Paulo Alcobia (paulo-alcobia)]

That is great brain what is the version of the "not new Msys2" please?

regards,
Paulo

[Paulo Alcobia (paulo-alcobia)]

Thank you for the changes but...
The hard way instructions still fail because mingw-w64-x86_64-ngspice is not available. And this is not explained anywhere in the text. Also there is no reference to the broken status of the current Msys2 distribution of to a version that works. This will likely be problematic to people that like me don't know what they are doing (that is why it is called "research" and development) and need help usually by following updated instructions. It's good that the easy way was removed because it didn't work and is was just making people waste their time, but making peoples lives more complicated doesn't help the "Kicad Cause/Community" there should always be an easy way if we want people tu use what ever product we are making. I Know C++ but I don't care much about the build environment and can't afford to spend weeks trying to figure it out. Seeing those instructions created some expectations that things would be easy and I could give it a try. I don't think its just me, but it could be my QA background.

Thank you for the work done so far, I appreciate it and I'm also just trying to help,
Paulo

[Brian Piccioni (br0an)]

I assume this is addressed to me.

I had tried reinstalling msys2 from scratch in order to build Kicad numerous times according the "easy way" instructions and another tool winmakekicad. I had also built OCE from scratch.

I had (I thought) previously tried to build Kicad the not easy way and failed previously.

Reinstalling msys2 takes time and has the potential for screwing up other things I am doing. Because I figured the most recent "not easy way" build instructions would fail I ran them without reinstalling Msys2 fresh. This make for release and debug versions worked.

As such, it may be that the history of my Msys installation or some other thing like having built OCE may have enabled the build to work.

I just thought I'd mention it in case it mattered.

So, long story short my Msys2 is a relatively recent (past few weeks version), updated with pacman -Syuu a few times and not a fresh, virgin install.

Does that make sense?

Brian

-----Original Message-----
From: <email address hidden> <email address hidden> On Behalf Of Paulo Alcobia
Sent: March 24, 2018 8:01 AM
To: <email address hidden>
Subject: [Bug 1752150] Re: Build from source MSYS2 the Easy Way Fails

That is great brain what is the version of the "not new Msys2" please?

regards,
Paulo

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1752150

Title:
  Build from source MSYS2 the Easy Way Fails

Status in KiCad:
  Fix Committed

Bug description:
  As per the title, after numerous attempts, this fails on Windows 10.

  I completely installed Msys2 and made sure there were no other
  instances.

  $ makepkg-mingw -is

  runs for several minutes and fails with

  "CMake Error at CMakeLists.txt:577 (find_package):
    By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
    asked CMake to find a package configuration file provided by "OCE", but
    CMake did not find one.

    Could not find a package configuration file provided by "OCE" (requested
    version 0.16) with any of the following names:

      OCEConfig.cmake
      oce-config.cmake

    Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
    to a directory containing one of the above files. If "OCE" provides a
    separate development package or SDK, be sure it has been installed."

  Initially these files were not in my computer. I went to the directory
  mingw-w64-oce
  and there were only 3 files: oce-i686.install, oce-x86_64.install, and PKGBUILD. The only one I could figure out what to do with was PKGBUILD, so I ran

  $ makepkg-mingw -is

  within mingw-w64.

  This ran for several hours. It gave me errors

  "-- Configuring done
  CMake Warning in adm/cmake/TKGeomAlgo/CMakeLists.txt:
    The object file directory

      C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-
  OCE-0.17.2/build-
  x86_64-w64-mingw32/adm/cmake/TKGeomAlgo/CMakeFiles/TKGeomAlgo.dir/

    has 145 characters. The maximum full path to an object file is 250
    characters (see CMAKE_OBJECT_PATH_MAX). Object file

  __/__/__/drv/Geom2dInt/Geom2dInt_SequenceNodeOfSeqPCOfPCLocFOfTheLocateExtPCOfTheProjPCurOfGInte...

[Jon Evans (craftyjon)]

Paulo, I'm guessing you don't see the ngspice package because you haven't synchronized pacman

Try running:

pacman -Syu

from a msys2 shell. You'll need to repeat this process if it updates some core components, so I recommend running it, closing the shell once it is done, and then repeating to be sure. After that, you should be able to install ngspice package.

I understand your frustration in getting KiCad building on Windows. It is hard to maintain up-to-date build instructions for all platforms when we don't really have that many developers (and many of them only use Linux or MacOS). It is time-consuming to "start from scratch" to make sure that things actually work from the ground up, so it doesn't happen as often as it would in a commercial setting with a dedicated software QA team. Please keep reporting issues with our documentation when you come across them and we'll try to keep up as dependencies change.

[Paulo Alcobia (paulo-alcobia)]

Yes, you are right, I did it now and it works.
thanks a lot.