Solution project Accord.NET (LGPL-only).sln fail to compile

[michel-carbone]

What would you like to submit? (put an 'x' inside the bracket that applies)

• question
• bug report
• feature request

Issue description

If you would like to submit an issue, please include a sample of the code you are trying to execute, as well as any data you might be using in your experiment, such as data tables, images, anything that might be necessary to reproduce the problem.

Note: If you would like to support the development for this feature or resolution of this bug, consider adding a bounty to it later in https://www.bountysource.com/teams/accord-net/issues

Hello César,

Following issue #979 I am trying to compile the solution project Accord.NET (LGPL-only).sln but the build fails because Accord.Math.Core is required as reference for Accord.Math which is required by many other libraries. Is it correct that Accord.Math.Core is not LGPL? What would be the work-arround for this dependency? If I add the Accord.Math.Core and Accord.DataSets projects in the solution Accord.NET (LGPL-only).sln its compiles fine. In the headers of the source files of Accord.Datasets it seems that all code is LGPL and it is the same for Accord.Math.Core. These dll are not output in GPL folder when I compile the full version of Accord framework. Could you clarify this point?

Best regards,
Michel

P.S. see michel-carbone@baf4693

[cesarsouza]

Hi @michel-carbone,

Thanks for opening the issue, and sorry for the contretemps. Accord.Math.Core is indeed LGPL, the problem is that the Accord.NET (LGPL-only) solution hadn't been updated in a while. I will update it soon after I finish working on some FFmpeg-related issues.

Regards,
Cesar

[michel-carbone]

hI @cesarsouza

No problem. I've seen that the solution file was created with VS2013 and that you recommend VS2017 for the full project. Can I propose you a pull request for the update of Accord.NET (LGPL-only) that build successfully? I've corrected also some class diagrams files *.cd that were still referencing AForge namespace.

Can I ask you on which FFmpeg related issues you are working? you are talking about your new issue #1001 ?
Is also a LGPL version of FFmpeg version part of this issue? I am also trying to achieve this goal. One option for me is to get the same 3.2.2 version build in LGPL and rebuild accordingly the Accord.Video.FFmpeg library. This option has the advantage that it will not break the current interface of the Accord.Video.FFmpeg library for this major version of Accord (i.e. 3.x.x).

Best regards,
Michel

[cesarsouza]

Hi @michel-carbone,

Absolutely, if you would like to update the LGPL-only project please feel free to do so!

Regarding the FFmpeg issues, I am working mostly on #1001. That rewrite is meant to make it easier to fix audio-related issues, such as #356 and #959. Thus said, having a LGPL version of FFmpeg is not part of that issue.

However, once that issue is completed, it should be easier to use a more recent version of FFmpeg if we need to. Might be useful if you don't manage to recompile FFmpeg 3.2.2 under the LGPL but manage to do so with a more recent version.

Regards,
Cesar

[cesarsouza]

Hi @michel-carbone,

Again thanks a lot for the PR. I've developed a bit upon it and added some missing configuration options that were available in Accord.NET.sln but were not available in the non-LGPL project. I've obviously certified that the build was not broken for me, but I hope I didn't break the compilation for you for some unforeseen reason.

Thanks again!

Regards,
Cesar