[CMake] Status/use of CMake on Cygwin

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon May 20 16:17:34 EDT 2013


On 2013-05-20 12:31+0200 Alexander Neundorf wrote:

> On Monday 20 May 2013, Alan W. Irwin wrote:
>> On 2013-05-19 21:06-0000 David Cole wrote:
>>> Disclaimer: I have found (over the years) the Cygwin environment to
>>
>> be ridiculously, enormously slow and frustrating, and have literally
>> completely given up on it as a realistic development environment. I
>> personally do not use it or install it, EVER. It’s probably been 3-4
>> years since I had one of my machines that had any form of Cygwin on
>> it.
>>
>> Hi David (off list again but this time with CC to Bill):
>>
> ...
>> I am thinking of implementing this idea using the Python-based jhbuild
>> package (developed originally to organize builds of the many different
>> gtk-associated software packages on Linux and Windows) since I have
>> some experience using jhbuild and thought it was a well-designed tool
>> to help users build software packages.  But obviously another
>> alternative for this job would be an overall CMakeLists.txt file.
>
> The kde-on-windows team is maintaining a python script called "emerge" (yes,
> the same name as under Gentoo, but it is not related to it) to build a whole
> bunch of packages, including downloading them, etc.
> Maybe you can have a look at that too, and see whether this could also be
> something which could be extended ?
> http://techbase.kde.org/Getting_Started/Build/Windows/emerge

Hi Alex:

I am now glad I put my post on list by accident since the result was
your interesting response about emerge. Thanks for reminding me of
emerge which I have been aware of but which I have not had a chance to
use. In the old days I had my own shell script to build KDE and Qt
which took 7 (!) days on a pentium-133 to complete, but this was long
before emerge was implemented and by the time I became aware of that,
I was reasonably satisfied by the standard distribution builds of
KDE/Qt and had no need to build KDE/Qt for myself.

Can you comment further on this note about emerge from the above web
page?

"Note 1: Be sure that you neither have the msys/bin nor the cygwin/bin
in your path."

If that constraint is absolutely required, then it is an emerge
showstopper for me for anything other purpose than to build KDE and
its dependencies. MSYS is important to me since I use a lot of bash
scripts and MSYS executables for tests for the software packages I am
directly responsible for, and I think that might be the case for a
number of additional software packages as well.  I presume the above
constraint is caused by emerge using the "MinGW Makefiles" generator
which checks there is no sh.exe (supplied by MSYS) on the PATH (for a
reason which I am sure is valid, but which I don't understand). But
for those software packages where MSYS is a necessity, could emerge be
configured to use the "MSYS Makefiles" generator instead (with a
temporary change to put MSYS on the PATH just for the affected
packages) to avoid this issue completely?

The other important general issue is that the proposed build-script
for open-source software on Windows should be able to build both
GNOME/GTK and KDE/Qt and all their dependencies on Windows.  But all
the GTK dependencies are already configured to be built with jhbuild
while KDE and Qt dependencies are already configured to be built with
emerge.  So to avoid doing all that GTK emerge configuration work by
hand, it would be ideal to have an automatic translator that would
produce an emerge configuration from a jhbuild configuration or vice
versa if I decided to go with jhbuild instead.  So is there such an
automatic translator one way or the other?

Of course, another alternative is an overall shell script to build
open-source software on Windows that uses emerge for KDE and
dependencies, jhbuild for GNOME and dependencies, and either emerge or
jhbuild for the rest of the open-source software that is covered by
that build script.

These remnants of the KDE/GNOME "not invented here" wars can
be frustrating, but there is usually a way around them.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list