kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/25/2014 5:14 PM, Brian Sidebotham wrote:
> On 25 October 2014 17:22, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> I've been working on packaging KiCad on MSYS2 with mingw64 and mingw32.
>>  I have everything building including the full Python scripting.
>> Unfortunately our current install paths when building with mingw don't
>> match up with the msys/mingw file structure.  The msys/mingw file
>> structure is the same as linux except for the library binaries which get
>> installed in the bin/ folder in order for the executable to be able to
>> find the libraries.  I propose that we change our windows install paths
>> to be the same as linux except for the kiface libraries.  Our path
>> search code can be simplified since windows and linux have the same
>> relative install paths.  Our windows install would look like
>>
>> # Path for executable and shared objects.
>> ${CMAKE_INSTALL_PREFIX}/bin
>>
>> # Path for documentation.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/doc
>>
>> # Path for demo projects.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/demos
>>
>> # Path for project templates.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/templates
>>
>> # Path for component libraries.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/library
>>
>> # Path for plugings.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/plugins
>>
>> # Path for data files.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad
>>
>> # Path for footprint library files when no GitHub.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/modules
>>
>> # Path for 3D model libraries.
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/share/modules/packages3D
> 
> I presume this would be ${CMAKE_INSTALL_PREFIX}/share/kicad/modules/packages3D

Yes.  Cut and paste error.

> 
> I think both modules directories should be changed now to footprint.
> We've made the decision to move to footprint, so let's give the user
> an easier life by being consistent. We probably need the code to drop
> back to the modules directory to maintain compatibility though.

We could do that.  It might cause some issues for folks who have and
environment variable that they are using in fp-lib-table.  As of right
now, the footprint libraries are still installed in the /module path.

> 
> Other than that, the paths all look sane to me.
> 
> 
>> If no one objects to these changes, I will update our install paths
>> accordingly and submit the kicad package build file to the msys2
>> project.  Hopefully, soon you will be able to install msys2 and install
>> kicad by running the `pacman -S`.
> 
> Sounds good.
> 
> I really don't want to get to a point where KiCad on Windows has MSYS
> as a dependency. I have a pretty big dislike of MSYS myself.

MSYS2 is only required to build the kicad package.  The actual binaries
are mingw64 or mingw32 with no dependencies on msys2.  MSYS2 is
significantly better than the original MSYS in virtually every way.
It's still not linux in that there is the occasional path conversion
quirk.  The standard packages are very current which means that most of
the build tools are the latest and greatest versions.  In fact both
mingw32 and mingw64 have the latest release version of GTK+ already
packaged.  The reason I am using it is that all of the dependencies
required to build kicad including a properly patched version of boost
1.56 and wxPython are already packaged.  All you have to do is install
them.  No more building any dependencies from source on windows.  Yeah!!!!

> 
> I think we should start a new project. Something like
> KiCad-Wininstaller or simiar, it doesn't really matter what it's
> called. It's normal for the binary packages to be provided by separate
> projects and not by the main project itself, it's not unusual.
> 
> I was hoping someone would step up and take KiCad-Winbuilder there,
> really there's not much more to do for it other than globbing the
> output into an installer. I believe that's pretty much what Milan has
> been doing.
> 
> Once we have a lightweight stable release marked it'll make more sense
> for someone to take on the Windows packaging role.
> 
> Best Regards,
> 
> Brian.
>