[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lighter build matrix on a language specific fork.


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-E55524197F0E@xxxxxxxxxxx>
  "Re: Lighter build matrix on a language specific fork. " on Fri, 7 Sep 2018 10:47:03 +0200,
  Romain Francois <romain@xxxxxxxxxxx> 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 <wesmckinn@xxxxxxxxx> 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 <romain@xxxxxxxxxxx> 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 <wesmckinn@xxxxxxxxx> 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 <uwelk@xxxxxxxxxx> 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 <antoine@xxxxxxxxxx> 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
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>>> 
>