[graalvm-dev] Avoiding NINJA dependency

[Foivos Zakkak]

Hi Josef,

On 29/04/2020 09:55, Josef Eisl wrote:
> Hi Foivos!
>
> On 28/04/2020 22:34, Foivos Zakkak wrote:
>> Hi Christian,
>>
>> The issue is that the build system does not have internet access and it
>> also doesn't support pypi, thus the build fails when trying to fetch
>> ninja_syntax (ninja can be installed through the repositories but
>> ninja_syntax is not available). We can add exceptions but we try to keep
>> those to a minimum.
> It seems like ninja_syntax is a single python file with ~180 lines
> coming directly from the ninja project. Isn't there is some way of
> getting this file onto your build system? (For example, it is included
> in the ninja-build src rpm as far as I can tell.)

Yes. We are also exploring this option (probably adding it to the ninja
package).

>> Would a change like the one suggested by Gilles, that would make mx
>> resort to makefiles only when a special parameter is passed to mx, be
>> acceptable?
> Maybe but how to ensure that things wont break? Running every CI job
> twice (at least those with a ninja project dependency which is almost
> everything in graalvm) to see that the generated Makefiles do the same
> as the Ninja build seems like spending a lot of resources.
>
> That said, I would not veto such a change if you agree to maintain it,
> but IMHO it seems like a lot of afford for a "package not available on
> the build infrastructure" kind of issue.

I agree, this is something we would like to avoid as well.

Thanks for the input,
Foivos

> Cheers,
> Josef
>
>> The Makefiles should preferably be generated to avoid the need of
>> maintaining them and we could add checks to allow the use of this flag
>> only on specific platforms. 
>>
>> Thanks,
>> Foivos
>>
>> On 28/04/2020 21:42, Christian Wimmer wrote:
>>> Hi,
>>>
>>> Ninja is a pretty established build tool. Why is the dependency a problem?
>>> Our initial hand-written make files were not portable (especially to 
>>> Windows). Automatically generating make files (or nmake files on 
>>> Windows) seems like making things worse.
>>>
>>> -Christian
>>>
>>>
>>> On 4/28/20 06:31, Foivos Zakkak wrote:
>>>> Hello all,
>>>>
>>>> I am trying to avoid the dependency on NINJA when building native 
>>>> libraries like libchelper.
>>>> Are you aware of any way to achieve this without manually writing Makefiles?
>>>>
>>>> Additionally, if I were to write the required Makefiles and alter the 
>>>> corresponding suite.py files is there any chance such a change would 
>>>> make it upstream or is NINJA the only way forward?
>>>> I see that makefiles are only used by sulong at the moment.
>>>>
>>>> Thanks
>>>> -- 
>>>>
>>>> Foivos Zakkak
>>>>
>>>> Senior Software Engineer, R&D Product Middleware
>>>>
>>>> Red Hat 
>>>> <https://urldefense.com/v3/__https://www.redhat.com__;!!GqivPVa7Brio!IxC-AQYSTh7M2kDyVowp6AdQFBTypGVR3YBR31dp586yDD2u6XGy0_Nxre--NZSYbjpwaA$> 
>>>>
>>>>
>>>> 7B4069D929BAAE91C0B3220A0846BFD103F04EA1
>>>>
>>>>
>>>> _______________________________________________
>>>> GraalVM-Dev mailing list
>>>> GraalVM-Dev at oss.oracle.com
>>>> https://oss.oracle.com/mailman/listinfo/graalvm-dev
>>>>
>>> _______________________________________________
>>> GraalVM-Dev mailing list
>>> GraalVM-Dev at oss.oracle.com
>>> https://oss.oracle.com/mailman/listinfo/graalvm-dev
>>>
>>>
>>> _______________________________________________
>>> GraalVM-Dev mailing list
>>> GraalVM-Dev at oss.oracle.com
>>> https://oss.oracle.com/mailman/listinfo/graalvm-dev
>
> _______________________________________________
> GraalVM-Dev mailing list
> GraalVM-Dev at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/graalvm-dev

-- 
Foivos Zakkak
Senior Software Engineer, R&D Product Middleware
Red Hat
7B4069D929BAAE91C0B3220A0846BFD103F04EA1 (keys.gnupg.net)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://oss.oracle.com/pipermail/graalvm-dev/attachments/20200429/71a0b34d/attachment-0001.bin