building windows packages under wine/linux and cross-compiling.

[Hin-Tak Leung-2]

Had some fun today, and thought it might be a good idea to share
and possibly for inclusion to R/src/gnuwin32/README.packages .

Wine/linux : while R, ActiveState Perl, mingw all works alright under
wine, the blocking issue is Rtool's cygwin dependency. forking
(as much of make and sh is forking sub-processes)
on posix-on-win32-on-posix currently doesn't work.
(http://wiki.winehq.org/CygwinSupport)

Cross-compiling: The instruction in R/src/gnuwin32/README.packages
essentially works, with one missing detail: "R_EXE=/usr/bin/R" is also
needed. Thus it should be:

     make R_EXE=/usr/bin/R PKGDIR=/mysources RLIB=/R/win/library \
             pkg-mypkg
     make P_EXE=/usr/bin/R KGDIR=/mysources RLIB=/R/win/library \
             pkgcheck-mypkg

Hin-Tak Leung

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Prof Brian Ripley]

On Mon, 31 Jul 2006, Hin-Tak Leung wrote:

> Had some fun today, and thought it might be a good idea to share
> and possibly for inclusion to R/src/gnuwin32/README.packages .

[...]

> Cross-compiling: The instruction in R/src/gnuwin32/README.packages
> essentially works, with one missing detail: "R_EXE=/usr/bin/R" is also
> needed. Thus it should be:
>
>      make R_EXE=/usr/bin/R PKGDIR=/mysources RLIB=/R/win/library \
>              pkg-mypkg
>      make P_EXE=/usr/bin/R KGDIR=/mysources RLIB=/R/win/library \
>              pkgcheck-mypkg

The instructions do work for those who actually follow them! That file
says

  Edit MkRules to set BUILD=CROSS and the appropriate paths (including
  HEADER) as needed.

and the appropriate section of that file is

## =================== cross-compilation settings  =================

ifeq ($(strip $(BUILD)),CROSS)
# Next might be mingw32- or i386-mingw32msvc- or i586-
# depending on the cross-compiler.
BINPREF=i586-mingw32-
# Set this to where the mingw32 include files are. It must be accurate.
HEADER=/users/ripley/R/cross-tools5/i586-mingw32/include
endif
# path (possibly full path) to same version of R on the host system
# R_EXE=R

and please do note the last two lines.

--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  [phone] (self)
1 South Parks Road,                     [phone] (PA)
Oxford OX1 3TG, UK                Fax:  [phone]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Hin-Tak Leung-2]

Prof Brian Ripley wrote:

> On Mon, 31 Jul 2006, Hin-Tak Leung wrote:
>
>> Had some fun today, and thought it might be a good idea to share
>> and possibly for inclusion to R/src/gnuwin32/README.packages .
>
> [...]
>
>> Cross-compiling: The instruction in R/src/gnuwin32/README.packages
>> essentially works, with one missing detail: "R_EXE=/usr/bin/R" is also
>> needed. Thus it should be:
>>
>>      make R_EXE=/usr/bin/R PKGDIR=/mysources RLIB=/R/win/library \
>>              pkg-mypkg
>>      make P_EXE=/usr/bin/R KGDIR=/mysources RLIB=/R/win/library \
>>              pkgcheck-mypkg
>
> The instructions do work for those who actually follow them! That file
> says
>
>   Edit MkRules to set BUILD=CROSS and the appropriate paths (including
>   HEADER) as needed.

Apologies... but in fact I did *not* edit HEADER, and essentially did
not understand the 2nd part of the above sentence, either.

Would it be better phrased as '...BUILD=CROSS near the top, and HEADER,
R_EXE, etc in the "cross-compilation settings" section in the middle
of the file' ? Better still, have it in MkRules itself:

   # Alternatives MINGW (mingw), CROSS (Linux)
   #  - if you change BUILD, remember to edit and adjust the relevant
   #    native/cross cofiguration section further down
   BUILD=MINGW

This is all about user-friendliness/useability...

> ## =================== cross-compilation settings  =================
>
> ifeq ($(strip $(BUILD)),CROSS)
> # Next might be mingw32- or i386-mingw32msvc- or i586-
> # depending on the cross-compiler.
> BINPREF=i586-mingw32-
> # Set this to where the mingw32 include files are. It must be accurate.
> HEADER=/users/ripley/R/cross-tools5/i586-mingw32/include
> endif
> # path (possibly full path) to same version of R on the host system
> # R_EXE=R
>
> and please do note the last two lines.

I did not modify the HEADER line - and it wasn't necessary -
I guess mingw32 either knows the header files is right next to the
compiler, picked up enough from linux glibc's headers, or what not.

On a different note, I am rather uncomfortable doing *both*
makefile editing and setting options on the comand lines
"make option1=value1 option2=vaule2 ...". Surely it is possible
to do it entirely one way, e.g.

  make CROSS_ON_LINUX=1 <rest_of_options>

or have the switching inside the makefile itself? e.g. (probably
wrong syntax - and depends on cygwin uname which isn't in Rtools)

     ifeq ($(uname -a),Linux)
     BUILD=CROSS
     else
     BUILD=MINGW
     endif

Hin-Tak Leung

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Hin-Tak Leung-2]

Hin-Tak Leung wrote:
> Prof Brian Ripley wrote:
>> On Mon, 31 Jul 2006, Hin-Tak Leung wrote:
>>
>>> Had some fun today, and thought it might be a good idea to share
>>> and possibly for inclusion to R/src/gnuwin32/README.packages .
>>
<snipped>
>>
>>   Edit MkRules to set BUILD=CROSS and the appropriate paths (including
>>   HEADER) as needed.
>
<snipped>
> On a different note, I am rather uncomfortable doing *both*
> makefile editing and setting options on the comand lines
> "make option1=value1 option2=vaule2 ...". Surely it is possible
> to do it entirely one way, e.g.
>
>  make CROSS_ON_LINUX=1 <rest_of_options>
<snipped>

After setting PATH=/mingw/bin, *without editing MkRules at all*,
this does work (note "BUILD=CROSS"):

       make BUILD=CROSS R_EXE=/usr/bin/R PKGDIR=/home/hin-tak/tmp-cvs \
          RLIB=/tmp pkg-snpMatrix

Apparently any variables ("BUILD" being one) specified on the make
command line overrides what's in the make file. Thus there is no need
to edit MkRules at all - HEADER can be specified in the same way
if needed (although it doesn't seem needed).

I'd prefer to do it this way - don't want to keep a locally
modified MkRules in my hard disc which differs from as-distributed
or as-installed (under wine).

There is a slight caveate - wine (and so does windows) installs
R under C:\Program Files\R\R-<version> , and cross-build doesn't like
the space in "Program Files". (native build seems to be able to address
that as c://progr~1/...). Instead of taking it off and reinstall,
I opted for sshfs-fuse mounting my ".wine/drive_c/Program Files/R"
elsewhere without a space in the path.

HTL

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Hin-Tak Leung-2]

Prof Brian Ripley wrote:
> This is make-specific.  It is true for GNU make, but not for BSD-like
> makes (and you can also cross-compile from FreeBSD and Solaris x86).

I know it is very possibly GNU make specific -
but that section in R/src/gnuwin32/README.package specifically says
"Cross-building packages on Linux", so that section could benefit
with a bit of updating.

(plus mentioning that cross-compile from FreeBSD and Solaris x86 is
also possible - although there would be a few more loops to jump
though, not having convenient ready-made cross-gcc binaries).

Not modifying as-distributed or as-installed files is quite
an important point... besides wine, I can imagine somebody using
a proper windows partition via dual boot or via network'ed smbmount
for doing cross-compile's.

HTL

> On Wed, 2 Aug 2006, Hin-Tak Leung wrote:
>
>> Hin-Tak Leung wrote:
>>> Prof Brian Ripley wrote:
>>>> On Mon, 31 Jul 2006, Hin-Tak Leung wrote:
>>>>
>>>>> Had some fun today, and thought it might be a good idea to share
>>>>> and possibly for inclusion to R/src/gnuwin32/README.packages .
>> <snipped>
>>>>   Edit MkRules to set BUILD=CROSS and the appropriate paths (including
>>>>   HEADER) as needed.
>> <snipped>
>>> On a different note, I am rather uncomfortable doing *both*
>>> makefile editing and setting options on the comand lines
>>> "make option1=value1 option2=vaule2 ...". Surely it is possible
>>> to do it entirely one way, e.g.
>>>
>>>  make CROSS_ON_LINUX=1 <rest_of_options>
>> <snipped>
>>
>> After setting PATH=/mingw/bin, *without editing MkRules at all*,
>> this does work (note "BUILD=CROSS"):
>>
>>        make BUILD=CROSS R_EXE=/usr/bin/R PKGDIR=/home/hin-tak/tmp-cvs \
>>           RLIB=/tmp pkg-snpMatrix
>>
>> Apparently any variables ("BUILD" being one) specified on the make
>> command line overrides what's in the make file. Thus there is no need
>> to edit MkRules at all - HEADER can be specified in the same way
>> if needed (although it doesn't seem needed).
>>
>> I'd prefer to do it this way - don't want to keep a locally
>> modified MkRules in my hard disc which differs from as-distributed
>> or as-installed (under wine).
>>
>> There is a slight caveate - wine (and so does windows) installs
>> R under C:\Program Files\R\R-<version> , and cross-build doesn't like
>> the space in "Program Files". (native build seems to be able to address
>> that as c://progr~1/...). Instead of taking it off and reinstall,
>> I opted for sshfs-fuse mounting my ".wine/drive_c/Program Files/R"
>> elsewhere without a space in the path.
>>
>> HTL
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Uwe Ligges]

Hin-Tak Leung wrote:

> Prof Brian Ripley wrote:
>
>>This is make-specific.  It is true for GNU make, but not for BSD-like
>>makes (and you can also cross-compile from FreeBSD and Solaris x86).
>
>
> I know it is very possibly GNU make specific -
> but that section in R/src/gnuwin32/README.package specifically says
> "Cross-building packages on Linux", so that section could benefit
> with a bit of updating.
>
> (plus mentioning that cross-compile from FreeBSD and Solaris x86 is
> also possible - although there would be a few more loops to jump
> though, not having convenient ready-made cross-gcc binaries).
>
> Not modifying as-distributed or as-installed files is quite
> an important point... besides wine, I can imagine somebody using
> a proper windows partition via dual boot or via network'ed smbmount
> for doing cross-compile's.

I cannot imagine: Why should one want to perform difficult cross
compiling if you have Windows available?
And why should I run R under wine? If I like Windows, I use Windows, if
I have like Linux, there is no reason to run R under wine.

Uwe Ligges

>
> HTL
>
>
>>On Wed, 2 Aug 2006, Hin-Tak Leung wrote:
>>
>>
>>>Hin-Tak Leung wrote:
>>>
>>>>Prof Brian Ripley wrote:
>>>>
>>>>>On Mon, 31 Jul 2006, Hin-Tak Leung wrote:
>>>>>
>>>>>
>>>>>>Had some fun today, and thought it might be a good idea to share
>>>>>>and possibly for inclusion to R/src/gnuwin32/README.packages .
>>>
>>><snipped>
>>>
>>>>>  Edit MkRules to set BUILD=CROSS and the appropriate paths (including
>>>>>  HEADER) as needed.
>>>
>>><snipped>
>>>
>>>>On a different note, I am rather uncomfortable doing *both*
>>>>makefile editing and setting options on the comand lines
>>>>"make option1=value1 option2=vaule2 ...". Surely it is possible
>>>>to do it entirely one way, e.g.
>>>>
>>>> make CROSS_ON_LINUX=1 <rest_of_options>
>>>
>>><snipped>
>>>
>>>After setting PATH=/mingw/bin, *without editing MkRules at all*,
>>>this does work (note "BUILD=CROSS"):
>>>
>>>       make BUILD=CROSS R_EXE=/usr/bin/R PKGDIR=/home/hin-tak/tmp-cvs \
>>>          RLIB=/tmp pkg-snpMatrix
>>>
>>>Apparently any variables ("BUILD" being one) specified on the make
>>>command line overrides what's in the make file. Thus there is no need
>>>to edit MkRules at all - HEADER can be specified in the same way
>>>if needed (although it doesn't seem needed).
>>>
>>>I'd prefer to do it this way - don't want to keep a locally
>>>modified MkRules in my hard disc which differs from as-distributed
>>>or as-installed (under wine).
>>>
>>>There is a slight caveate - wine (and so does windows) installs
>>>R under C:\Program Files\R\R-<version> , and cross-build doesn't like
>>>the space in "Program Files". (native build seems to be able to address
>>>that as c://progr~1/...). Instead of taking it off and reinstall,
>>>I opted for sshfs-fuse mounting my ".wine/drive_c/Program Files/R"
>>>elsewhere without a space in the path.
>>>
>>>HTL
>>>
>>>______________________________________________
>>>[hidden email] mailing list
>>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Hin-Tak Leung-2]

Uwe Ligges wrote:
<snipped>
>
> I cannot imagine: Why should one want to perform difficult cross
> compiling if you have Windows available?
> And why should I run R under wine? If I like Windows, I use Windows, if
> I have like Linux, there is no reason to run R under wine.

*You* cannot imagine.

I am an almost exlusively linux person. An acquitance, also a
mainly linux person, for teaching purpose, asked for windows binary
of something I (co-)wrote, to be installed on to the teaching machines.
Installing too many development tools on teaching machines is not
an option; so the other option, than cross-compiling, is to
*borrow* a windows machine *set up for development purposes*.
(which I did, at the start).

I cannot, and would not, keep on repeatedly borrowing other
people's windows development machines, which they have possibly
spent some time in setting up; besides, they may not have all
the tools, and/or willing to put things like Mingw or ActiveState
Perl on their machines. I did have to install both, plus the
latest version of R - in my first native try, and immediately
de-installing them from the borrowed machine as soon as I finished.

You are not involved in any teaching roles, I reckon? And you haven't
written any packages that you would like others to use, on a
different platform from your own?

Since I am cross-compiling, it goes that I would like to test
the result of cross-compiling right-away under wine, without
switching machine or rebooting (in case of dual boot). In fact I
found and fix a bug in my code, which *only* shows up under
wine's implementation of msvcrt, not on win2k's or glibc's - wine's
msvcrt behavior is valid ANSI C, but different from MS win2k
or linux glibc's. (and nobody can say for sure win2k's msvcrt is
exactly the same as NT, XP, etc's).

HTL

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Duncan Murdoch]

On 8/2/2006 6:05 PM, Hin-Tak Leung wrote:

> Uwe Ligges wrote:
> <snipped>
>> I cannot imagine: Why should one want to perform difficult cross
>> compiling if you have Windows available?
>> And why should I run R under wine? If I like Windows, I use Windows, if
>> I have like Linux, there is no reason to run R under wine.
>
> *You* cannot imagine.
>
> I am an almost exlusively linux person. An acquitance, also a
> mainly linux person, for teaching purpose, asked for windows binary
> of something I (co-)wrote, to be installed on to the teaching machines.
> Installing too many development tools on teaching machines is not
> an option; so the other option, than cross-compiling, is to
> *borrow* a windows machine *set up for development purposes*.
> (which I did, at the start).
>
> I cannot, and would not, keep on repeatedly borrowing other
> people's windows development machines, which they have possibly
> spent some time in setting up; besides, they may not have all
> the tools, and/or willing to put things like Mingw or ActiveState
> Perl on their machines. I did have to install both, plus the
> latest version of R - in my first native try, and immediately
> de-installing them from the borrowed machine as soon as I finished.
>
> You are not involved in any teaching roles, I reckon? And you haven't
> written any packages that you would like others to use, on a
> different platform from your own?
>
> Since I am cross-compiling, it goes that I would like to test
> the result of cross-compiling right-away under wine, without
> switching machine or rebooting (in case of dual boot). In fact I
> found and fix a bug in my code, which *only* shows up under
> wine's implementation of msvcrt, not on win2k's or glibc's - wine's
> msvcrt behavior is valid ANSI C, but different from MS win2k
> or linux glibc's. (and nobody can say for sure win2k's msvcrt is
> exactly the same as NT, XP, etc's).

What I'd recommend you do is get an old laptop with Windows installed on
it, and install the development tools there.  There are probably several
lying around peoples' offices in your department.  If you found bugs in
your code because of differences between wine and Windows, you're also
bound to find bugs in wine, and waste a lot of time trying to see what's
wrong with your code when really there's nothing at all wrong with it.

You'll also soon find people complaining that your package doesn't
contain compiled HTML help, because there's no Linux tool to build that.

Windows machines are cheap.  You don't need a new one to build a package
or to run R.  I can't imagine there is any change to the build procedure
that would cost less in our time than the cost to you of getting an old
Windows box.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Sean Davis]

Duncan Murdoch wrote:

> On 8/2/2006 6:05 PM, Hin-Tak Leung wrote:
>
>>Uwe Ligges wrote:
>><snipped>
>>
>>>I cannot imagine: Why should one want to perform difficult cross
>>>compiling if you have Windows available?
>>>And why should I run R under wine? If I like Windows, I use Windows, if
>>>I have like Linux, there is no reason to run R under wine.
>>
>>*You* cannot imagine.
>>
>>I am an almost exlusively linux person. An acquitance, also a
>>mainly linux person, for teaching purpose, asked for windows binary
>>of something I (co-)wrote, to be installed on to the teaching machines.
>>Installing too many development tools on teaching machines is not
>>an option; so the other option, than cross-compiling, is to
>>*borrow* a windows machine *set up for development purposes*.
>>(which I did, at the start).
>>
>>I cannot, and would not, keep on repeatedly borrowing other
>>people's windows development machines, which they have possibly
>>spent some time in setting up; besides, they may not have all
>>the tools, and/or willing to put things like Mingw or ActiveState
>>Perl on their machines. I did have to install both, plus the
>>latest version of R - in my first native try, and immediately
>>de-installing them from the borrowed machine as soon as I finished.
>>
>>You are not involved in any teaching roles, I reckon? And you haven't
>>written any packages that you would like others to use, on a
>>different platform from your own?
>>
>>Since I am cross-compiling, it goes that I would like to test
>>the result of cross-compiling right-away under wine, without
>>switching machine or rebooting (in case of dual boot). In fact I
>>found and fix a bug in my code, which *only* shows up under
>>wine's implementation of msvcrt, not on win2k's or glibc's - wine's
>>msvcrt behavior is valid ANSI C, but different from MS win2k
>>or linux glibc's. (and nobody can say for sure win2k's msvcrt is
>>exactly the same as NT, XP, etc's).
>
>
> What I'd recommend you do is get an old laptop with Windows installed on
> it, and install the development tools there.  There are probably several
> lying around peoples' offices in your department.  If you found bugs in
> your code because of differences between wine and Windows, you're also
> bound to find bugs in wine, and waste a lot of time trying to see what's
> wrong with your code when really there's nothing at all wrong with it.
>
> You'll also soon find people complaining that your package doesn't
> contain compiled HTML help, because there's no Linux tool to build that.
>
> Windows machines are cheap.  You don't need a new one to build a package
> or to run R.  I can't imagine there is any change to the build procedure
> that would cost less in our time than the cost to you of getting an old
> Windows box.

Or dual-boot your existing linux machine...?

Sean

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Vincent Goulet]

Le Mercredi 2 Août 2006 21:33, Duncan Murdoch a écrit :

> On 8/2/2006 6:05 PM, Hin-Tak Leung wrote:
> > Uwe Ligges wrote:
> > <snipped>
> >
> >> I cannot imagine: Why should one want to perform difficult cross
> >> compiling if you have Windows available?
> >> And why should I run R under wine? If I like Windows, I use Windows, if
> >> I have like Linux, there is no reason to run R under wine.
> >
> > *You* cannot imagine.
> >
> > I am an almost exlusively linux person. An acquitance, also a
> > mainly linux person, for teaching purpose, asked for windows binary
> > of something I (co-)wrote, to be installed on to the teaching machines.
> > Installing too many development tools on teaching machines is not
> > an option; so the other option, than cross-compiling, is to
> > *borrow* a windows machine *set up for development purposes*.
> > (which I did, at the start).
> >
> > I cannot, and would not, keep on repeatedly borrowing other
> > people's windows development machines, which they have possibly
> > spent some time in setting up; besides, they may not have all
> > the tools, and/or willing to put things like Mingw or ActiveState
> > Perl on their machines. I did have to install both, plus the
> > latest version of R - in my first native try, and immediately
> > de-installing them from the borrowed machine as soon as I finished.
> >
> > You are not involved in any teaching roles, I reckon? And you haven't
> > written any packages that you would like others to use, on a
> > different platform from your own?
> >
> > Since I am cross-compiling, it goes that I would like to test
> > the result of cross-compiling right-away under wine, without
> > switching machine or rebooting (in case of dual boot). In fact I
> > found and fix a bug in my code, which *only* shows up under
> > wine's implementation of msvcrt, not on win2k's or glibc's - wine's
> > msvcrt behavior is valid ANSI C, but different from MS win2k
> > or linux glibc's. (and nobody can say for sure win2k's msvcrt is
> > exactly the same as NT, XP, etc's).
>
> What I'd recommend you do is get an old laptop with Windows installed on
> it, and install the development tools there.  There are probably several
> lying around peoples' offices in your department.  If you found bugs in
> your code because of differences between wine and Windows, you're also
> bound to find bugs in wine, and waste a lot of time trying to see what's
> wrong with your code when really there's nothing at all wrong with it.
>
> You'll also soon find people complaining that your package doesn't
> contain compiled HTML help, because there's no Linux tool to build that.
>
> Windows machines are cheap.  You don't need a new one to build a package
> or to run R.  I can't imagine there is any change to the build procedure
> that would cost less in our time than the cost to you of getting an old
> Windows box.
>
> Duncan Murdoch

I already wrote this to Hin-Tak privately but will repeat it here "for the
record": use VMWare for Windows development on a Linux host (or the other way
around, or any other combination for that matter). The Server version is now
free. It's a great product. No need to reboot or to have a separate computer.
A virtual one (or two, or...) is right there on your desktop.

HTH

--
  Vincent Goulet, Professeur agrégé
  École d'actuariat
  Université Laval, Québec
  [hidden email]   http://vgoulet.act.ulaval.ca

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Seth Falcon-2]

Uwe Ligges <[hidden email]> writes:
> I cannot imagine: Why should one want to perform difficult cross
> compiling if you have Windows available?  And why should I run R
> under wine? If I like Windows, I use Windows, if I have like Linux,
> there is no reason to run R under wine.

One use-case for running R under wine is for a package developer to be
able to test her packages on Windows without having to have a Windows
box.

At least in Bioconductor, a vast majority of package developers use
Linux for their development.  Finding ways to allow them to test on
Windows (where a majority of _users_ are found) makes a lot of sense
to me.

And I'm pretty sure that cross-compilation is quite easy.  Just like
building R from source on Windows, you just follow the 16 easy steps
and it works ;-)

+ seth

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel