The rpath issue does not need to be resolved right now, though. I will review the patch again and merge if all looks good
On Fri, Sep 7, 2018 at 4:53 AM Kouhei Sutou <k...@clear-code.com> wrote: > Hi, > > We can get Arrow's library directory by > "pkg-config --variable=libdir arrow". Does this help this case? > > Thanks, > -- > kou > > In <4712da01-7d10-44aa-971b-e55524197...@purrple.cat> > "Re: Lighter build matrix on a language specific fork. " on Fri, 7 Sep > 2018 10:47:03 +0200, > Romain Francois <rom...@purrple.cat> wrote: > > > Addressed most of the comments. Anyone knows how to set rpath > dynamically in: > > https://github.com/apache/arrow/pull/2489#discussion_r215875597 < > https://github.com/apache/arrow/pull/2489#discussion_r215875597> > > > > Maybe pkg-config can help ? > > > >> Le 7 sept. 2018 à 00:40, Wes McKinney <wesmck...@gmail.com> a écrit : > >> > >> OK, if you could address the comments that I left, after that I can > merge > >> the PR > >> > >> On Thu, Sep 6, 2018 at 8:39 AM Romain François <rom...@purrple.cat> > wrote: > >> > >>> As far as I’m concerned the initial pr is good to go, the intent is to > >>> just have an r package that builds against the C++ library and that > checks > >>> on travis. > >>> > >>> Actual code that does stuff will follow. (I have two branches on top > of it > >>> for later). > >>> > >>> But this is bare minimal by design. > >>> > >>> Romain > >>> > >>>> Le 7 sept. 2018 à 00:06, Wes McKinney <wesmck...@gmail.com> a écrit : > >>>> > >>>> Yes, as soon as the initial R PR is in (and the CI scripts aren't > >>> changing) > >>>> the build will be faster. > >>>> > >>>> @Romain how much more work do you want to do on the initial PR? We can > >>>> review and merge by end of week if that sounds good > >>>> > >>>>> On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote: > >>>>> > >>>>> The problem could be that it checks against master and you will > probably > >>>>> have changes for R in the ci/ directory. Changes in that directory > will > >>>>> trigger a build for the full matrix. So to get the build simple and > >>> fast, > >>>>> we should get the ci/ changes for R into master soon. > >>>>> > >>>>> Uwe > >>>>> > >>>>>> On Thu, Sep 6, 2018, at 3:04 PM, Antoine Pitrou wrote: > >>>>>> > >>>>>>> Le 06/09/2018 à 15:03, Romain François a écrit : > >>>>>>> I must do something wrong then because it builds them all, all the > >>>>> time 🤷♂️. > >>>>>> > >>>>>> Can you show an example? > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Not a big deal, it’s only about 10 jobs, and i really only care > about > >>>>> the r job and the only doing the 🐀 analysis. > >>>>>>> > >>>>>>> Commenting out may not be very practical as the plan is to submit > >>>>> small pull requests, so it’s almost guaranteed i’ll forget to > uncomment > >>>>> about 50% of the time. > >>>>>>> > >>>>>>>> Le 6 sept. 2018 à 14:48, Antoine Pitrou <anto...@python.org> a > écrit > >>>>> : > >>>>>>>> > >>>>>>>> > >>>>>>>> Our CI harness will already fast-exit in jobs that are not > affected > >>> by > >>>>>>>> the current changes (if you change only the R directory, C++ jobs > >>> will > >>>>>>>> exit early). > >>>>>>>> > >>>>>>>> If you want it to be even faster, your best bet is to temporarily > >>>>>>>> comment out job entries in .travis.yml. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> Antoine. > >>>>>>>> > >>>>>>>> > >>>>>>>>> Le 06/09/2018 à 14:26, Romain François a écrit : > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> Is there a way to have a lighter build matrix on travis, perhaps > >>>>> based on the branch name, for example when working on the r bindings > and > >>>>> not touching anything else, having only the r job to be triggered > would > >>>>> make it faster for travis. > >>>>>>>>> > >>>>>>>>> For example when working on r features i would typically start > the > >>>>> branch name with « r-» > >>>>>>>>> > >>>>>>>>> Romain > >>>>>>>>> > >>>>>>> > >>>>> > >>> > >>> > > >
