kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 5 April 2011 19:57, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>
>>>> 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.

I have been looking at this tonight. In fact the built-in tar
functions of cmake are okay for the purposes of having wxWidgets as an
external project.

I started by looking to see if cmake could automate the installation
of mingw. I'm not sure this is going to be possible. Cmake will not
seemingly process anything unless if finds a working compiler to begin
with. So although cmake is capable of downloading and running the
mingw installer on windows, it won't because there isn't already a
working compiler. A bit of a paradox really. CmakeForceCompiler.cmake
doesn't help here.

Although, that said, installing MinGW on windows is now extremely
simple, it can be done on the command line, like so:

mingw-get install gcc g++ gdb mingw32-make

It's a shame this isn't a built-in Windows command!!

So I think MinGW will have to stay as a pre-requisite to building
KiCad until that problem can be solved.

wxWidgets should integrate as an external project using external_add.
I have tested this and got cmake to download, decompress and build
wxWidgets, but it'll some more work before it's ready.

Because KiCad is already a cmake enabled project, it should be a very
simple job to include that as an external project. It should work out
very easy.

Incidentally the editing of wxWidgets/include/wx/msw/setup.h is no
longer needed in wxWidgets version 2.9.1 for building on windows and
so presumably that is still true in 2.9.2 onwards. I mentioned  this
change in my build instructions, but it is no longer needed for the
newer versions of wxWidgets.


>
> 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.

Yes, in actual fact I think a linux cross-build version using MinGW is
possibly more important than the Windows version. I don't mind looking
into that after I at least get windows doing things correctly.

> 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?
>

Bazaar shouldn't be a problem. The only problematic thing is trying to
get cmake to perform actions before it detects a working compiler (as
mentioned above). I will ask on the cmake mailing list to see if it is
possible to tell cmake to do tasks before barfing because there is no
valid compiler.

> 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.

No problem, and I agree a Linux cross-compiling version would be great.

>
>> 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!

It's great, right up until mingw32-make has issues properly using the
-j option! It won't build wxWidgets with the -j option specified.

However, KiCad builds on this box infinitely faster than on my old box
so I'm sure I must be able to be more productive on it! ;-)

Best Regards,

Brian.