kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

>>> For MS Windows in particular (cross building from Linux or not, both), and
>>> other platforms too, I still say there is tremendous value in us providing
>>> cmake "external project" support to build wxWidgets and anything else that
>>> needs to be built.  This is a separate subject.  But I've given it some
>>> thought on how to best do it so we do not munge our current Kicad build
>>> cmake stack, which would remain as is.  Basically it would entail putting an
>>> *optional* CMakeList.txt wrapper around everything, platform dependent, and
>>> treating Kicad itself as an external project from there along with all the
>>> other external projects.
>> I think this is a good idea.  When (if?) I get some time, I will play around
>> with it but it's off my radar for right now.
>>
>> Wayne
>>
> I started looking into this, and came to the same conclusion - that it
> would be best to have a kicad builder cmake project which would
> download wxWidgets, configure + build, and then download the kicad
> source, configure and build.
>
> On windows this makes a lot of sense. However, when you scratch the
> surface, you see the windows weaknesses. For example, there is no way
> to unzip something via the command line on a standard windows install.



There is the whole gnuwin32 collection of *.exe's. 

    http://gnuwin32.sourceforge.net/


Some of these may need to be installed upfront manually or automatically. 
CMake does have some decompression technology in it, at least for tar.gz and
maybe you have some choice on which source bundle you download in some
cases, being careful to select one supported by CMake.   But I'll bet the
Windows build of CMake is sub-setted in this support, aw crap.


So if we have moved this outside our standard cmake script, and it is
platform specific, why then a cmake script at all, why not a batch file or
something else?



1))))))
Once this works on Windows, I think there is value in getting one similar to
it to work on Linux to build the Windows Kicad.  So maybe asking for a
broader starting point keeps some of the Windows specific weaknesses out of
the CMakeLists.txt file for those that would copy & modify it to make a
cross compiler version.  But then again, there is the MINGW cmake define:

if( MINGW AND UNIX )

    I am cross compiling here

endif()


For the Linux version, you have the toolchain file to worry about when
invoking the external project called Kicad, a sample is in the /new
directory.  I know you are not committing to doing a cross compile version,
but we have somebody on this list (Milan, a good volunteer) who needs it
badly, since he keeps Windows binaries up to date.


2))))))
It is an easy way to tell Kicad's CMakeCache.txt file, by properly doing the
initial CMake invocation on the Kicad cmake script, where the other packages
are, since you now know exactly.



So on Windows, what is the "starting point"?  No idea really.  Go install
Linux, really.  (Well not really, just kidding.)


1) Install CMake.
2) Download your wrapper CMakeLists.txt file.
3) Run it


Notice I did not mention install MinGW, or bazaar.  If this is hard to do
with CMake, then maybe the "starting point" is broader, driven by a batch
file, and post install MinGW, post install bazaar?


I've already spent more than a year's quota worrying about what happens on
Windows and for Windows.  This is enough for me.


Thanks for your help Brian.   From my point of view, the Linux version of
this is more doable, and more important as a means of creating Windows Kicad
binaries.


> I took some time out from looking at it because I've been building my
> new PC, so now I'm on a Core I7 2600k with 8Gb of RAM and a PCI-E SSD
> hard disk I'm likely to become a lot more productive!

Damn you must be a fast typer.  No way are you going to get ahead of your
box now!