kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

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

> On 01/17/2013 08:56 AM, Miguel Angel Ajo Pelayo wrote:
> >
> >
> >
> > 2013/1/17 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto: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.
>
> ??
>
> Was thinking you would maintain a full hg python tree, with the CMake
> stuff in there all
> the time.
> This way you can pull from upstream, and generate a diff which constitutes
> the CMake patch
> at any time.
>
> The form of David's work now is actually pretty inconvenient to use, since:
>
> a) it is not actually a patch but rather an overlay.
> b) he makes the mingw stuff optional, and it should not be.
>
> In your shoes I would maintain a full separate python tree in hg, say
> perhaps on google
> code if they support hg.
>
>
>
Another DVCS system? (waaahhhh)... ';-)

Will give it a try when we have something that can go upstream for 3.x


> >
> >
> >
> >     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.
>
> It will be a larger problem getting the patch accepted here than in 3.x,
> according to
> python mailing list postings I've read.
>
> Your 3.x work is important now in my opinion.  Feel free to build a team
> of helpers.
>
>
>
> >
> >
> >     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.
>
>
> I do not agree.  The 3.x patch will be easier for the python developers to
> accept,
> according to mailing list postings.
>
>
Yes, but 3.x yet feels like bleeding edge for me (wx python with 3.x still
not available
by default in most linux distros as Wayne investigated).

I feel more like we must be prepared for the 3.x switch, but not to do it
right now, because
that means a some rewriting here and there in our own code (not much
really, but some),
and also more pain for linux users.



>
> >
> >
> >
> >     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.
>
> Think reverse psychology....  tell them they cannot have them first....  :)
>
>
I was thinking more about KiCad users, that python users :-), but you're
right in that case :-)


>
> Use CPack within CMake for your windows pre-built packages, this just keys
> off of the
> install() commands.
>
> It is a totally elegant solution using NSI installer on windows.
>
>
Nice!! :) didn't know that, that makes cmake even more awesome.



> If your deliverable is superior to anything out there, i.e. the
> installation package, then
> folks will want to merge your diffs from your python tree.
>
>
 :-)


>
> >
> >
> >
> >     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?
>
> I have used CPack, it hinges off of CMake install() commands, so you are
> half done.
>
> Feel free to build a team and get maybe Wayne, Brian, and Adam to help in
> the various parts.
>
>
>
>
> >
> >
> >
> >
> >     >
> >     > Miguel Angel Ajo
> >     > http://www.nbee.es
> >     > +34911407752 <tel:%2B34911407752>
> >     > skype: ajoajoajo
> >     >
> >     > On 16/01/2013, at 19:50, Miguel Angel Ajo Pelayo <
> miguelangel@xxxxxxx
> >     <mailto: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 <tel:%2B34911407752>
> >     >> skype: ajoajoajo
> >     >>
> >     >> On 16/01/2013, at 19:31, Dick Hollenbeck <dick@xxxxxxxxxxx
> >     <mailto: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
>
>


-- 

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