[Audacity-devel] 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

[Darrell Walisser]

On Fri, Jun 2, 2017 at 10:02 PM, Surya Kiran Gullapalli <

Post by 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

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.

Post by Surya Kiran Gullapalli
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.

[Gale Andrews]

Post by Darrell Walisser
On Fri, Jun 2, 2017 at 10:02 PM, Surya Kiran Gullapalli

Post by 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

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

Post by Darrell Walisser

Post by Surya Kiran Gullapalli
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Surya Kiran Gullapalli]

Post by Darrell Walisser

Post by Darrell Walisser
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

Post by Darrell Walisser
anything changed in lib-src, where autotools is more robust in that

respect.

Post by Darrell Walisser
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

Post by Darrell Walisser
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

Post by Darrell Walisser
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

[Roger Dannenberg]

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

Post by Darrell Walisser

Post by Darrell Walisser
If your cmake system could avoid changes under lib-src,

supported all

Post by Darrell Walisser
platforms (including OS X, cross-compiling, Travis, etc) it

would be more

Post by Darrell Walisser
likely to be accepted. The downside is it would be fragile with

respect to

Post by Darrell Walisser
anything changed in lib-src, where autotools is more robust in

that respect.

Post by Darrell Walisser
However, the same is true for the Xcode and VisualStudio project

files so

Post by Darrell Walisser
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

Post by Darrell Walisser
update libs to latest versions!). I don't know how this came

about, but I

Post by Darrell Walisser
can imagine there has been a lot of time spent (lost) because a

library was

Post by Darrell Walisser
updated and obscure bugs started to appear, all without

providing much

Post by Darrell Walisser
benefit to the user. In otherwords, if a change to 3rd party lib

doesn't fix

Post by Darrell Walisser
a bug, it's seen as a bug opportunity. There is also concern

about merge

Post by Darrell Walisser
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel