kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

2013/1/17 Dick Hollenbeck <dick@xxxxxxxxxxx>

> Nice job, I am glad I was able to inspire you to see the light.
>

Just did nothing but follow the readme, it's good that you found it. I hope
I will be able to port it to the latest 2.7.x python, anyway, I will
consider that low priority, it's not a stopper at all.


>
> This approach puts the task firmly in your comfort zone.
>

Mine, and everybody's I hope, the python build scripts are a mess :-)


> It would not be unreasonable for you to be a maintainer of your very own
> Mingw-Python for
> Windows binaries, you know, like a rock star, I mean package maintainer.


I forked the cmake script so in the case we do some enhancements I will
send them back for merge.


>
> Remember that python has to compile with gcc for linux, so the python
> source is always
> going to be mostly acceptable for mingw-gcc.
> You only have to worry about the boundaries such as system calls and
> library functions.
>
> It does not seem overly difficult to maintain a big ass patch indefinitely
> if the python
> guys prove too stubborn for your CMake preferences.
>

Well, the 2.7.x branch must be maintaned only for security and bugs, but no
new features, so it should be not a problem.


> You could have a separate patch for 3.x python as well, and compete with
> them on superior
> packaging until they see the light.  Use CMake packaging to keep it simple
> and fast.
>

Hehe, 3.x is another war, that we must fight later :-), but we must keep
that in mind and write 2.7 - 3.x compatible code.


>
> The benefits of CMake are so extreme that I would not rule out making a
> build environment
> in it for wxWidgets or even wxPython.
>
> Just think of maintaining your trees in whatever version control system
> the upstream folks
> are using, this way you can always regenerate your patches.  But to be
> honest, you may not
> even have to distribute your patches, depending on license.
>

Well I have no problem in distributing the patches or build script, I think
it's something important to the community,
to have the freedom to rebuild them as needed.


>
> The trees do not necessarily comprise your product, your "product" is the
> 6 pre-built
> Windows packages, suitable for download and installation by KiCad users as
> a minimum.
>
>
Well, I took all that mess (with the benefits too) to KiCad so It's fair to
make it my task will keep you updated
on the efforts, more during tomorrow night, tomorrow I must deliver some
software release for a client.


>
> On 01/16/2013 02:52 PM, Miguel Angel Ajo Pelayo wrote:
> > cmake + python 2.7.1 mingw cross compilation worked here too, for some
> reason cmake tried to link
> > "dl" and failed, I skipped that manually, and worked :-)
> >
> > That -ldl failure happened to you too Dick?
>
> Yes, but I did not mention it because we know how easy it is to edit
> CMakeLists.txt
> files.  Comfortable territory.
>

Ok, that's good that it wasn't my system only.


I'd love to be able to make the 6 stones, (prebuilt packages) and also
manage to auto-build kicad for win32,
so we can start delivering a testing win32 build for all the users.

Anybody has experience in building windows installers with something free?


>
>
> >
> > Miguel Angel Ajo
> > http://www.nbee.es
> > +34911407752
> > skype: ajoajoajo
> >
> > On 16/01/2013, at 19:50, Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>
> wrote:
> >
> >> This project is full of valuable developers,
> >>
> >> I really like the cmake / cross compiling idea, that could lead to
> success and also
> >> automated KiCad/Win32 builds at any time …
> >>
> >> I'm going to try it!! (pausing the swig-gsoc2012-doxygen tests, which
> look good)
> >>
> >> I will also try the cross-path with Wayne instructions when they are
> available and see where do we get.
> >>
> >> Miguel Angel Ajo
> >> http://www.nbee.es
> >> +34911407752
> >> skype: ajoajoajo
> >>
> >> On 16/01/2013, at 19:31, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> >>
> >>> On 01/16/2013 11:16 AM, Miguel Angel Ajo Pelayo wrote:
> >>>> Other option we could have right now is compile out the wxpython
> support and provide
> >>>> only embedded python scripting + python pcbnew module for windows
> users.
> >>>>
> >>>> In that case, next functionalities are lost:
> >>>>
> >>>> 1) PyCrust shell inside pcbnew
> >>>> 2) Ability to create and run own wx-uis in the embedded python
> scripting.
> >>>>
> >>>> And we keep:
> >>>>
> >>>> 3) pcbnew module for commandline python scripting
> >>>> 4) embedded pcbnew wizards & plugins
> >>>>
> >>>> Wayne, could you document the steps you followed until now so I can
> try to reproduce it and fight a little bit in this war ?
> >>>
> >>>
> >>> In a half hour last night, I was able to cross compile python for
> windows, on linux, using
> >>> mingw32.
> >>>
> >>> Just get source to tag v2.7.1 python using hg,  then apply David's
> cmake patch.
> >>>
> >>> Build a simple CMAKE_TOOLCHAIN_FILE for your linux mingw toolset, and
> it built just fine.
> >>>
> >>> CMake, Linux, Mingw, cross-compiling, and money are my answer to any
> problems in this topic.
> >>>
> >>> Since they don't exist in sufficient quantity, I am now dropping out
> of this topic.
> >>>
> >>> The talk about using microsoft tools getting pulled back into the
> project are too painful
> >>> to even participate in.
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo