Re: [Kicad-developers] Translation building changes in master

2021-01-21 Thread Ian McInerney 
Yes, Steve made me aware of the lack of that file on older distros - and I
am working on a solution. I am currently building out the CMake files so
that they try to do the translation and then check the return code and
fallback to a simple file copy if the translation fails (and display the
failure as a warning, so it is visible but doesn't stop the build process).

-Ian

On Thu, Jan 21, 2021 at 5:12 PM Steven A. Falco 
wrote:

> We have the same problem with Fedora 32 because it also doesn't have the
> needed ITS file.
>
> I believe Ian is looking into a solution.
>
> Steve
>
> On 1/21/21 11:40 AM, Jean-Samuel Reynaud wrote:
> > Dear Ian,
> >
> > Since this update some build fail on ubuntu. In fact there is
> > translation of some XML files (for example mime types
> > resources/linux/mime/kicad-gerbers.xml.in) but gettext is unable to find
> > rules to translate that kind of file without the appropriate ITS file.
> > On Ubuntu 18.04, shared-mime-info is too old and don't ship
> > shared-mime-info.loc and shared-mime-info.its. So building is failing.
> >
> > So what is your proposal for that ? Perhaps there is already an answer
> > about this point ? I think I can fix that by coping missing ITS files on
> > the appropriate directory but it's a dirty solution...
> >
> >
> >
> >
> > Le 18/01/2021 à 18:54, Ian McInerney a écrit :
> >> The changes to the i18n build system have now been merged into the
> >> master branch - with the change that KICAD_BUILD_I18N will default to
> >> OFF now, so it must be enabled when you want to build the translations
> >> libraries.
> >>
> >> At this point, all nightly builds of the master branch that include
> >> translations need to be updated to use the KICAD_BUILD_I18N=ON flag and
> >> no longer reference the i18n repository.
> >>
> >> -Ian
> >>
> >> On Sat, Jan 16, 2021 at 7:41 PM Ian McInerney  >> > wrote:
> >>
> >>  Since we now host the v6 translations inside the main code
> >>  repository, I have consolidated the CMake scripts for building the
> >>  translation files into the main build process inside this MR
> >>  (https://gitlab.com/kicad/code/kicad/-/merge_requests/628). That
> >>  exposes a new CMake option `KICAD_BUILD_I18N`, which defaults to
> on,
> >>  that controls if the translations are built. When that option is
> ON,
> >>  gettext is a required dependency and when it is off it is not
> >>  needed. This change will require some people to modify their
> current
> >>  build setup to disable the translations if they do not wish to
> build
> >>  with gettext.
> >>
> >>  In that MR I have also added the linux metadata files to the
> >>  translation framework to allow for the strings contained inside
> them
> >>  to be internationalized (so that the user sees translated strings
> on
> >>  desktop icons/tooltips in their display manager). That should be a
> >>  transparent change to the packagers of nightly builds, but a
> welcome
> >>  change for users.
> >>
> >>  -Ian
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Translation building changes in master

2021-01-21 Thread Steven A. Falco 

We have the same problem with Fedora 32 because it also doesn't have the needed 
ITS file.

I believe Ian is looking into a solution.

Steve

On 1/21/21 11:40 AM, Jean-Samuel Reynaud wrote:

Dear Ian,

Since this update some build fail on ubuntu. In fact there is
translation of some XML files (for example mime types
resources/linux/mime/kicad-gerbers.xml.in) but gettext is unable to find
rules to translate that kind of file without the appropriate ITS file.
On Ubuntu 18.04, shared-mime-info is too old and don't ship
shared-mime-info.loc and shared-mime-info.its. So building is failing.

So what is your proposal for that ? Perhaps there is already an answer
about this point ? I think I can fix that by coping missing ITS files on
the appropriate directory but it's a dirty solution...




Le 18/01/2021 à 18:54, Ian McInerney a écrit :

The changes to the i18n build system have now been merged into the
master branch - with the change that KICAD_BUILD_I18N will default to
OFF now, so it must be enabled when you want to build the translations
libraries.

At this point, all nightly builds of the master branch that include
translations need to be updated to use the KICAD_BUILD_I18N=ON flag and
no longer reference the i18n repository.

-Ian

On Sat, Jan 16, 2021 at 7:41 PM Ian McInerney mailto:ian.s.mciner...@ieee.org>> wrote:

 Since we now host the v6 translations inside the main code
 repository, I have consolidated the CMake scripts for building the
 translation files into the main build process inside this MR
 (https://gitlab.com/kicad/code/kicad/-/merge_requests/628). That
 exposes a new CMake option `KICAD_BUILD_I18N`, which defaults to on,
 that controls if the translations are built. When that option is ON,
 gettext is a required dependency and when it is off it is not
 needed. This change will require some people to modify their current
 build setup to disable the translations if they do not wish to build
 with gettext.

 In that MR I have also added the linux metadata files to the
 translation framework to allow for the strings contained inside them
 to be internationalized (so that the user sees translated strings on
 desktop icons/tooltips in their display manager). That should be a
 transparent change to the packagers of nightly builds, but a welcome
 change for users.

 -Ian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Translation building changes in master

2021-01-21 Thread Jean-Samuel Reynaud 
Dear Ian,

Since this update some build fail on ubuntu. In fact there is
translation of some XML files (for example mime types
resources/linux/mime/kicad-gerbers.xml.in) but gettext is unable to find
rules to translate that kind of file without the appropriate ITS file.
On Ubuntu 18.04, shared-mime-info is too old and don't ship
shared-mime-info.loc and shared-mime-info.its. So building is failing.

So what is your proposal for that ? Perhaps there is already an answer
about this point ? I think I can fix that by coping missing ITS files on
the appropriate directory but it's a dirty solution...




Le 18/01/2021 à 18:54, Ian McInerney a écrit :
> The changes to the i18n build system have now been merged into the
> master branch - with the change that KICAD_BUILD_I18N will default to
> OFF now, so it must be enabled when you want to build the translations
> libraries.
> 
> At this point, all nightly builds of the master branch that include
> translations need to be updated to use the KICAD_BUILD_I18N=ON flag and
> no longer reference the i18n repository.
> 
> -Ian
> 
> On Sat, Jan 16, 2021 at 7:41 PM Ian McInerney  > wrote:
> 
> Since we now host the v6 translations inside the main code
> repository, I have consolidated the CMake scripts for building the
> translation files into the main build process inside this MR
> (https://gitlab.com/kicad/code/kicad/-/merge_requests/628). That
> exposes a new CMake option `KICAD_BUILD_I18N`, which defaults to on,
> that controls if the translations are built. When that option is ON,
> gettext is a required dependency and when it is off it is not
> needed. This change will require some people to modify their current
> build setup to disable the translations if they do not wish to build
> with gettext.
> 
> In that MR I have also added the linux metadata files to the
> translation framework to allow for the strings contained inside them
> to be internationalized (so that the user sees translated strings on
> desktop icons/tooltips in their display manager). That should be a
> transparent change to the packagers of nightly builds, but a welcome
> change for users.
> 
> -Ian
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Odp: Re: Questions to the QA code

2021-01-21 Thread Jeff Young 
Good point.  I have only used the Java one (which I guess is the original?).

Cheers,
Jeff.


> On 20 Jan 2021, at 21:18, Sylwester Kocjan  wrote:
> 
> Hi Jeff,
> 
> Did you use https://github.com/tpounds/mockitopp 
>  or that one for Java 
> https://github.com/mockito/mockito  ?
> Mockitopp has it's last code update about ~1,5 year ago, so it looks it has 
> the same downside as HippoMocks.
> There is also Mockpp, also not actively developed: 
> https://sourceforge.net/projects/mockpp/ 
> 
> 
> BR,
> SK
> Dnia 17 stycznia 2021 16:45 Jeff Young  napisał(a):
> 
> I’ve used Mockito.  Can’t say I remember a thing about it, though (which 
> could be good?).
> 
> Cheers,
> Jeff.
> 
>> On 17 Jan 2021, at 14:49, Sylwester Kocjan < 
>> s.koc...@o2.pl > wrote:
>> 
>> Hello,
>> 
>> On 17/01/2021 09:47, Alex wrote:
>> > ...GTest, Doctest and Catch2, (...) they'll all get the job done
>> 
>> They are all testing frameworks without mocking capability. We have already 
>> Boost.Test based tests and I find it unnecessary effort to migrate them, and 
>> alone
>> they don't solve the problem. 
>> 
>> 
>> On 17/01/2021 09:47, Alex wrote:
>> > I wasn't aware that GMock could operate separately from GTest, but if it 
>> > can, that's pretty neat.
>> 
>> On Sun, Jan 17, 2021, 12:15 AM Andrew Lutsenko  
>>  wrote:
>> > You can also use gmock separately from gtest.
>> 
>> Since some time gmock is a part of gtest. Any search results in the topic of 
>> gmock with another testing frameworks are quite old. I think there is a risk 
>> that it will not work. 
>> 
>> 
>> On 17/01/2021 09:47, Alex wrote:
>> > Catch is a single header
>> 
>> I was instructed to avoid introducing new dependencies, hence my initial 
>> choice of single-header HippoMocks:
>> 
>> https://gitlab.com/kicad/code/kicad/-/issues/4446#note_445185505 
>> 
>> 
>> On Sat, Jan 16, 2021 at 6:47 AM Seth Hillbrand  
>>  wrote:
>> > The downside of HippoMocks from what I can gather is that the project 
>> > appears abandoned. 
>> 
>> Sadly, this is true. There are also other choices, but I don't have any 
>> hands-on experience with them and I don't know which one to choose:
>> - http://turtle.sourceforge.net/ 
>> - https://github.com/tpounds/mockitopp 
>> - https://github.com/rollbear/trompeloeil 
>> 
>> 
>> Best regards,
>> Sylwester
>> 
>> 
>> On 17/01/2021 09:47, Alex wrote:
>>> I've used GTest, Doctest and Catch2, and they'll all get the job done; 
>>> Doctest is definitely the fastest to compile, but also has the least of 
>>> features; Catch and GTest have the most features.
>>> 
>>> I wasn't aware that GMock could operate separately from GTest, but if it 
>>> can, that's pretty neat.
>>> 
>>> I believe Doctest and Catch both are single header - I know at least Catch 
>>> is a single header; but I think it makes sense to use a git submodule in 
>>> this case.
>>> 
>>> 
>>> On Sun, Jan 17, 2021, 12:15 AM Andrew Lutsenko < 
>>> anlutse...@gmail.com 
>>> > wrote:
>>> I would also suggest to look towards gtest/gmock. 
>>> It's widely adopted, works with cmake out of the box, has integrations with 
>>> popular IDEs and a good choice of supporting tools like parallelized 
>>> runners, GUI inspectors etc.
>>> You can also use gmock separately from gtest.
>>> 
>>> Andrew
>>> 
>>> On Sat, Jan 16, 2021 at 6:47 AM Seth Hillbrand < 
>>> s...@kipro-pcb.com > 
>>> wrote:
>>> Hi Sylwester-
>>> 
>>> I haven't used HippoMocks but in general, adding QA tests is always welcome 
>>> as long as they run as expected under the Fedora docker we use for online 
>>> QA with GitLab.
>>> 
>>> The downside of HippoMocks from what I can gather is that the project 
>>> appears abandoned.  If I'm incorrect here, can you link to the current 
>>> repository/documentation?
>>> 
>>> Thanks-
>>> Seth
>>> 
>>> On Fri, Jan 15, 2021 at 2:49 PM Sylwester Kocjan < 
>>> s.koc...@o2.pl > wrote:
>>> Hello,
>>> 
>>> I have two questions regarding QA code for KiCad and I'd like to ask for 
>>> your comments about them:
>>> 
>>> 1. I reviewed contents of qa directory in KiCad repo and I saw some issues 
>>> that can be fixed.
>>>Could you please take a look at the summary and let me know if they are 
>>> valid:
>>> 
>>> https://docs.google.com/spreadsheets/d/14QAy9rRIHqRr4YuXfQO2GicURAG1BgJmwKe7B1H6xXI/edit#gid=326687467
>>>  
>>> 
>>> 
>>> 2. What do you think