Cmake and Qt

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Cmake and Qt

Surya Kiran Gullapalli
Hello all,
I've been using Audacity for quite some time and I'd like to contribute to its development. Two areas of interest for me are cmake build system for audacity and Qt (5 preferably) gui for audacity. 

I'd like to know if there's interest in these two areas and also any development happening in these areas or I should start afresh.

I did see some discussions on Qt gui development for audacity, but I do not know if the development ever started. 

Thanks,
Surya



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cmake and Qt

Darrell Walisser


On Fri, Jun 2, 2017 at 10:02 PM, Surya Kiran Gullapalli <[hidden email]> wrote:
Hello all,
I've been using Audacity for quite some time and I'd like to contribute to its development. Two areas of interest for me are cmake build system

If your cmake system could avoid changes under lib-src, supported all platforms (including OS X, cross-compiling, Travis, etc) it would be more likely to be accepted. The downside is it would be fragile with respect to anything changed in lib-src, where autotools is more robust in that respect. However, the same is true for the Xcode and VisualStudio project files so you could make a valid argument to replace the autotools system.

There is general resistance to change anything at all in lib-src (even to update libs to latest versions!). I don't know how this came about, but I can imagine there has been a lot of time spent (lost) because a library was updated and  obscure bugs started to appear, all without providing much benefit to the user. In otherwords, if a change to 3rd party lib doesn't fix a bug, it's seen as a bug opportunity. There is also concern about merge difficulty when inevitably a bug is discovered which was fixed upstream.

for audacity and Qt (5 preferably) gui for audacity. 

I'd like to know if there's interest in these two areas and also any development happening in these areas or I should start afresh.

I did see some discussions on Qt gui development for audacity, but I do not know if the development ever started. 


I don't know of any serious development on this. From what I've seen wxWidgets is in almost every module. May as well refactor all the non-gui parts and write a new gui from scratch.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cmake and Qt

Gale
Administrator
On 3 June 2017 at 04:53, Darrell Walisser <[hidden email]> wrote:

>
>
> On Fri, Jun 2, 2017 at 10:02 PM, Surya Kiran Gullapalli
> <[hidden email]> wrote:
>>
>> Hello all,
>> I've been using Audacity for quite some time and I'd like to contribute to
>> its development. Two areas of interest for me are cmake build system
>
>
> If your cmake system could avoid changes under lib-src, supported all
> platforms (including OS X, cross-compiling, Travis, etc) it would be more
> likely to be accepted. The downside is it would be fragile with respect to
> anything changed in lib-src, where autotools is more robust in that respect.
> However, the same is true for the Xcode and VisualStudio project files so
> you could make a valid argument to replace the autotools system.
>
> There is general resistance to change anything at all in lib-src (even to
> update libs to latest versions!). I don't know how this came about, but I
> can imagine there has been a lot of time spent (lost) because a library was
> updated and  obscure bugs started to appear, all without providing much
> benefit to the user. In otherwords, if a change to 3rd party lib doesn't fix
> a bug, it's seen as a bug opportunity. There is also concern about merge
> difficulty when inevitably a bug is discovered which was fixed upstream.

Those type of issues have not happened often.  When we do update
lib-src we like to do it at the start of the development cycle for a
release, in the hope of catching those sort of problems.

I think the problem is more that we don't have developers on tap
who are experienced in updating lib-src. We had good proposals
formulated to update some of the libs at the start of 2.2.0-alpha,
but nothing happened.


Gale

>> for audacity and Qt (5 preferably) gui for audacity.
>>
>> I'd like to know if there's interest in these two areas and also any
>> development happening in these areas or I should start afresh.
>>
>> I did see some discussions on Qt gui development for audacity, but I do
>> not know if the development ever started.
>>
>
> I don't know of any serious development on this. From what I've seen
> wxWidgets is in almost every module. May as well refactor all the non-gui
> parts and write a new gui from scratch.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cmake and Qt

Surya Kiran Gullapalli

> If your cmake system could avoid changes under lib-src, supported all
> platforms (including OS X, cross-compiling, Travis, etc) it would be more
> likely to be accepted. The downside is it would be fragile with respect to
> anything changed in lib-src, where autotools is more robust in that respect.
> However, the same is true for the Xcode and VisualStudio project files so
> you could make a valid argument to replace the autotools system.
>
> There is general resistance to change anything at all in lib-src (even to
> update libs to latest versions!). I don't know how this came about, but I
> can imagine there has been a lot of time spent (lost) because a library was
> updated and  obscure bugs started to appear, all without providing much
> benefit to the user. In otherwords, if a change to 3rd party lib doesn't fix
> a bug, it's seen as a bug opportunity. There is also concern about merge
> difficulty when inevitably a bug is discovered which was fixed upstream.

Those type of issues have not happened often.  When we do update
lib-src we like to do it at the start of the development cycle for a
release, in the hope of catching those sort of problems.

I think the problem is more that we don't have developers on tap
who are experienced in updating lib-src. We had good proposals
formulated to update some of the libs at the start of 2.2.0-alpha,
but nothing happened.

​I can give it a try. But I do not have, at my disposal, all the supported platforms. I can at least test it on couple of platforms and can push the code into a separate branch and see how it goes. I'm currently trying to understand the autotools setup.

Surya


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
rbd
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cmake and Qt

rbd

I use CMake for several cross-platform projects, and I like it a lot. However, I find that there is still a lot of platform specific CMake code needed in practice. Nyquist has about 2000 lines of CMake, which seems excessive, but then I guess autotools would be pretty big, Linux only, and maybe it's just me, but I have a really hard time making sense of or using autotools. On the plus side, CMake gives you executable programs -- you can set variables, call functions, add print statements to debug, etc. This seems much more practical than trying to understand all the dependencies that get processed by Make (in spite of debug support in Make and in spite of how naturally Make's declarative approach seems to match the problem). Just to be clear, CMake uses and manages dependencies too, but it just seems to work better in practice. And I can't imagine how anyone could ever keep Audacity compiling under Visual Studio without CMake. I cringe just thinking about the thousands of parameters in a VS solution that all get set manually.

The main reason for writing this is just to say if you haven't tried CMake on a moderately big project like Audacity, you should be warned that it's a significant development project and you'll almost certainly decide after you get it working (if you get that far) that you did it wrong and you'll need some major restructuring to make something that can be read and maintained.

Although I like CMake, autotools are critical right now, so you might find some resistance to a switch, given that that will mean maintainers have to forget everything they know about autotools in Audacity and learn to navigate a new build system. It might be better to continue getting autotools updates from upstream libraries and invoking them from CMake (and doing something and doing something more CMake-like for VS and xcode) - this is all part of the learning curve.

-Roger


On 6/3/17 12:13 PM, Surya Kiran Gullapalli wrote:

> If your cmake system could avoid changes under lib-src, supported all
> platforms (including OS X, cross-compiling, Travis, etc) it would be more
> likely to be accepted. The downside is it would be fragile with respect to
> anything changed in lib-src, where autotools is more robust in that respect.
> However, the same is true for the Xcode and VisualStudio project files so
> you could make a valid argument to replace the autotools system.
>
> There is general resistance to change anything at all in lib-src (even to
> update libs to latest versions!). I don't know how this came about, but I
> can imagine there has been a lot of time spent (lost) because a library was
> updated and  obscure bugs started to appear, all without providing much
> benefit to the user. In otherwords, if a change to 3rd party lib doesn't fix
> a bug, it's seen as a bug opportunity. There is also concern about merge
> difficulty when inevitably a bug is discovered which was fixed upstream.

Those type of issues have not happened often.  When we do update
lib-src we like to do it at the start of the development cycle for a
release, in the hope of catching those sort of problems.

I think the problem is more that we don't have developers on tap
who are experienced in updating lib-src. We had good proposals
formulated to update some of the libs at the start of 2.2.0-alpha,
but nothing happened.

​I can give it a try. But I do not have, at my disposal, all the supported platforms. I can at least test it on couple of platforms and can push the code into a separate branch and see how it goes. I'm currently trying to understand the autotools setup.

Surya



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...