Ack, I will try to see if I can get GH actions.
It would also be better to have everything integrated in one place.

I remember the discussion and the PR… I had some comments which never got 
addressed.

Windows is pretty slow when starting processes ,especially if the builtin AV is 
not disabled for the directory you are building in. That is the main issue for 
the slow compile and test times.

Using cmake/meson is helpful because unlike the automake tools, they will 
generate a visual studio solution and that in turn can be built by invoking a 
single msbuild process. Since meson does not have something builtin for 
testing, I was wondering if it would make more sense switching to cmake/ctest… 

—
Alin

> On 8 Jun 2023, at 11:43, Ilya Maximets <i.maxim...@ovn.org> wrote:
> 
> On 6/8/23 11:01, Alin Serdean wrote:
>> 
>> Ack. I will try to see if I can address it by the end of the week.
>> 
>> Thanks for clarifying the questions.
>> 
>> Would GH actions be better than appveyor?
> 
> Functionally, I don't think they are that much different.
> But GHA is better integrated into our CI, i.e. ovsrobot
> reports GHA status per patch on a patchwork, but it doesn't
> do the same for appveyor.  So, having GHA job is probably
> not a bad idea.  We discussed most of the pros and cons
> about 2 years ago here:
>  https://github.com/openvswitch/ovs-issues/issues/209
> The main problem is that windows build is slow in general.
> But that shouldn't be a blocker for CI.
> 
> Best regards, Ilya Maximets.
> 
>> 
>> —
>> Alin.
>> 
>>> On 2 Jun 2023, at 12:25, Ilya Maximets <i.maxim...@ovn.org> wrote:
>>> 
>>> On 6/1/23 13:50, Ilya Maximets wrote:
>>>>> On 5/31/23 23:05, Alin Serdean wrote:
>>>>> 
>>>>> That makes sense.
>>>>> 
>>>>> We can leverage the  following commit:
>>>>> 
>>>>> https://patchwork.ozlabs.org/project/openvswitch/patch/20201013124655.1408-1-aserd...@cloudbasesolutions.com/
>>>>>  
>>>>> <https://patchwork.ozlabs.org/project/openvswitch/patch/20201013124655.1408-1-aserd...@cloudbasesolutions.com/>
>>>>> 
>>>>> But I still need to fix the permissions. I’ll try to find some time and 
>>>>> address it.
>>>> 
>>>> Thanks.  I actually forgot about this patch.  Would be great if you can
>>>> send an updated version.  Would also be great to migrate to OpenSSL 3.0
>>>> instead of 1.1.1 to not migrate again in some not so distant future.
>>>> OpenSSL 3.0 should work fine, unless there are some other library changes
>>>> (not OpenSSL 3.1, because OpenSSL 3.1 is not an LTS release).
>>> 
>>> I'll mark  the current patch as 'rejected' for now in favor of the
>>> future OpenSSL update with your suggested change.
>>> 
>>>> 
>>>>> I remember there were some discussions to modernize the build system to 
>>>>> meson or cmake. Was that effort fruitful in the end?
>>>> 
>>>> The main issue with meson is that we still need automake/autotools for
>>>> our testsuite.  We might invoke autotest from meson, but it sounds a
>>>> bit strange to do that.  I agree that it is still beneficial in some
>>>> cases to use meson, e.g. for a windows build, so might make sense to
>>>> migrate anyway, but an attempt from 2021 didn't receive any follow ups.
>>>> 
>>>> There was also a PR to add Windows build to GitHub Actions, but it
>>>> didn't move since your request to Sign-off the changes.
>>>> 
>>>> Best regards, Ilya Maximets.
>>>> 
>>>>> 
>>>>> Alin.
>>>>> 
>>>>>> On 31 May 2023, at 22:41, Ilya Maximets <i.maxim...@ovn.org> wrote:
>>>>>> 
>>>>>> On 5/31/23 22:36, Alin Serdean wrote:
>>>>>>> 
>>>>>>> It would be best to change the link with the latest version of OpenSSL. 
>>>>>>> That will ensure there are no mishaps .
>>>>>> 
>>>>>> I think the problem here is that slproweb.com only provides
>>>>>> OpenSSL 1.1.1+ right now and our build system doesn't work
>>>>>> with that version.  And I don't have enough experience with
>>>>>> windows build in order to fix it...
>>>>>> 
>>>>>> Best regards, Ilya Maximets.
>>>>>> 
>>>>>>> 
>>>>>>> Alin.
>>>>>>> 
>>>>>>>> 
>>>>>>>> On 31 May 2023, at 21:23, Ilya Maximets <i.maxim...@ovn.org> wrote:
>>>>>>>> 
>>>>>>>> OpenSSL is already available in the exact location we need it [1].
>>>>>>>> Also, the download itself fails for a long time already, because
>>>>>>>> the version we're trying to download is not available.
>>>>>>>> 
>>>>>>>> [1] https://www.appveyor.com/docs/windows-images-software/#tools
>>>>>>>> 
>>>>>>>> Signed-off-by: Ilya Maximets <i.maxim...@ovn.org>
>>>>>>>> ---
>>>>>>>> appveyor.yml | 14 --------------
>>>>>>>> 1 file changed, 14 deletions(-)
>>>>>>>> 
>>>>>>>> diff --git a/appveyor.yml b/appveyor.yml
>>>>>>>> index 25c3f69fb..3287733b2 100644
>>>>>>>> --- a/appveyor.yml
>>>>>>>> +++ b/appveyor.yml
>>>>>>>> @@ -11,22 +11,8 @@ init:
>>>>>>>> - ps: $env:PATH ="C:\Python37;"+$env:PATH
>>>>>>>> - ps: New-Item -Type HardLink -Path "C:\Python37\python3.exe" -Value 
>>>>>>>> "C:\Python37\python.exe"
>>>>>>>> - ps: >-
>>>>>>>> -    mkdir C:\ovs-build-downloads
>>>>>>>> -
>>>>>>>>   mkdir C:\openvswitch\driver
>>>>>>>> 
>>>>>>>> -    $source = "https://slproweb.com/download/Win64OpenSSL-1_0_2u.exe";
>>>>>>>> -
>>>>>>>> -    $destination = "C:\ovs-build-downloads\Win64OpenSSL-1_0_2u.exe"
>>>>>>>> -
>>>>>>>> -    Invoke-WebRequest $source -OutFile $destination
>>>>>>>> -
>>>>>>>> -    cd C:\ovs-build-downloads
>>>>>>>> -
>>>>>>>> -    .\Win64OpenSSL-1_0_2u.exe /silent /verysilent /sp- 
>>>>>>>> /suppressmsgboxes
>>>>>>>> -
>>>>>>>> -    Start-Sleep -s 30
>>>>>>>> -
>>>>>>>>   cd C:\openvswitch
>>>>>>>> 
>>>>>>>>   git clone https://git.code.sf.net/p/pthreads4w/code 
>>>>>>>> c:\pthreads4w-code
>>>>>>>> -- 
>>>>>>>> 2.40.1
>>>>>>>> 
>>>>>> 
>>>> 
>>> 
> 
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to