kicad-developers team mailing list archive

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


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


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


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.

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