Hi,

there was a "recent" change 
(https://github.com/csound/csound/commit/a6a17c5550f06c9323d02c1fcc0b09c94b5a7d63#diff-cbb69e8a67514ac4c02765caf1ee81f4d088a3aaf6d7be1892513d2aefb70009) 
by which include/version.h is autogenerated by cmake. This breaks lots 
of build actions by plugins and csoundqt, which would include csound as 
a submodule and add its include dir in their own cmake scripts in order 
to build without needing to have csound (and all its dependencies) 
installed. Is there any chance that this change can be reverted, or the 
generated version.h included in the tree?

Thanks!

Eduardo

I made that change because we kept getting versions wrong in releases and etc. It seems to do what we need, so I would prefer if we kept it. We then set the version in one place only and do not need to keep going to change the header file.

This works in the same way as the float-version.h auto generation.

The problem with keeping a static header is that it will eventually trip us. So reverting to the old way of doing things is preferred in that case.

Maybe we can work out a solution for CsoundQT that does not involve reverting to static version headers?

Is this a problem for Cabbage too?

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 23 Dec 2021, at 06:11, Eduardo Moguillansky  wrote:
> 
> *Warning*
> 
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> 
> Hi,
> 
> there was a "recent" change
> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fcommit%2Fa6a17c5550f06c9323d02c1fcc0b09c94b5a7d63%23diff-cbb69e8a67514ac4c02765caf1ee81f4d088a3aaf6d7be1892513d2aefb70009&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C43c60b2aa093442ccd5408d9c5dae9a9%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637758366713234060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZL0Kb%2F5Lawwa0z9yBuX34Tyn%2Bpff6gKvDUZnCM4w7WM%3D&reserved=0)
> by which include/version.h is autogenerated by cmake. This breaks lots
> of build actions by plugins and csoundqt, which would include csound as
> a submodule and add its include dir in their own cmake scripts in order
> to build without needing to have csound (and all its dependencies)
> installed. Is there any chance that this change can be reverted, or the
> generated version.h included in the tree?
> 
> Thanks!
> 
> Eduardo

The problem is that a complete build environment is needed just to have 
access to the csound headers. Particularly in a ci environment (like 
github actions) this means that instead of just having csound as a 
submodule we need to have everything needed for cmake to actually 
configure the csound project without errors and generate the .h files. 
Besides this, as per the nature of how cmake works inside another cmake 
project, it can be tricky to run the cmake script in csound when being 
included as submodule.

I would be really thankful for a static version.

Best regards,

Eduardo


On 23.12.21 12:51, Victor Lazzarini wrote:
> I made that change because we kept getting versions wrong in releases and etc. It seems to do what we need, so I would prefer if we kept it. We then set the version in one place only and do not need to keep going to change the header file.
>
> This works in the same way as the float-version.h auto generation.
>
> The problem with keeping a static header is that it will eventually trip us. So reverting to the old way of doing things is preferred in that case.
>
> Maybe we can work out a solution for CsoundQT that does not involve reverting to static version headers?
>
> Is this a problem for Cabbage too?
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 23 Dec 2021, at 06:11, Eduardo Moguillansky  wrote:
>>
>> *Warning*
>>
>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>
>> Hi,
>>
>> there was a "recent" change
>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fcommit%2Fa6a17c5550f06c9323d02c1fcc0b09c94b5a7d63%23diff-cbb69e8a67514ac4c02765caf1ee81f4d088a3aaf6d7be1892513d2aefb70009&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C43c60b2aa093442ccd5408d9c5dae9a9%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637758366713234060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZL0Kb%2F5Lawwa0z9yBuX34Tyn%2Bpff6gKvDUZnCM4w7WM%3D&reserved=0)
>> by which include/version.h is autogenerated by cmake. This breaks lots
>> of build actions by plugins and csoundqt, which would include csound as
>> a submodule and add its include dir in their own cmake scripts in order
>> to build without needing to have csound (and all its dependencies)
>> installed. Is there any chance that this change can be reverted, or the
>> generated version.h included in the tree?
>>
>> Thanks!
>>
>> Eduardo

The trouble is that the previous arrangement was problematic and it would be unfortunate to go back to it. I would prefer if we can find another solution.  CMake keeps everything displaying the right versions. In the past, we often got versions wrong, or forgot to update stuff after releases. 

Again it's one of those things that help
us maintain the software. Since we are very under stress at the moment (and I don't see anyone volunteering to keep Csound maintained and released), I prefer if we simplified rather than complicated things. 

How do you manage with float-version.h? That needs to be generated too.

Since the auto-generation of float-version was put in place (I think this was brought in by Felipe and Steven), the principle seems to be that the headers in the repo are not designed to be used directly, they need to be installed. It certainly helps us keep things correctly in sync. It tripped me up to start with but then I realised that I needed to work with installed headers. 

Certainly if we put a static version in the repo, it will end up out of sync because I'm sure we'll forget. So it's either the old way or some form of auto generation, but a combination of the two is sure trouble. It may work for API clients though, to have their own static version header locally (as some do for float-version, but that's probably simpler too).

Let's hear suggestions.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 23 Dec 2021, at 13:00, Eduardo Moguillansky  wrote:
> 
> The problem is that a complete build environment is needed just to have access to the csound headers. Particularly in a ci environment (like github actions) this means that instead of just having csound as a submodule we need to have everything needed for cmake to actually configure the csound project without errors and generate the .h files. Besides this, as per the nature of how cmake works inside another cmake project, it can be tricky to run the cmake script in csound when being included as submodule.
> 
> I would be really thankful for a static version.
> 
> Best regards,
> 
> Eduardo
> 
> 
>> On 23.12.21 12:51, Victor Lazzarini wrote:
>> I made that change because we kept getting versions wrong in releases and etc. It seems to do what we need, so I would prefer if we kept it. We then set the version in one place only and do not need to keep going to change the header file.
>> 
>> This works in the same way as the float-version.h auto generation.
>> 
>> The problem with keeping a static header is that it will eventually trip us. So reverting to the old way of doing things is preferred in that case.
>> 
>> Maybe we can work out a solution for CsoundQT that does not involve reverting to static version headers?
>> 
>> Is this a problem for Cabbage too?
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>>> On 23 Dec 2021, at 06:11, Eduardo Moguillansky  wrote:
>>> 
>>> *Warning*
>>> 
>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> 
>>> Hi,
>>> 
>>> there was a "recent" change
>>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fcommit%2Fa6a17c5550f06c9323d02c1fcc0b09c94b5a7d63%23diff-cbb69e8a67514ac4c02765caf1ee81f4d088a3aaf6d7be1892513d2aefb70009&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce47135c4e26048d08ef408d9c6141112%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637758612243589531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6N6FucSqV17w4xfcxSeEid8bD%2BY8nx%2B4du2vgJajdyY%3D&reserved=0)
>>> by which include/version.h is autogenerated by cmake. This breaks lots
>>> of build actions by plugins and csoundqt, which would include csound as
>>> a submodule and add its include dir in their own cmake scripts in order
>>> to build without needing to have csound (and all its dependencies)
>>> installed. Is there any chance that this change can be reverted, or the
>>> generated version.h included in the tree?
>>> 
>>> Thanks!
>>> 
>>> Eduardo

I don't see a solution which solves this and is simple enough not to become a burden of itself. A viable middle ground would be to include a static version of the includes in some other directory as a part of the release steps. Any projects needing such static includes can simply add that directory to their search path. I can send a PR but it would amount to creating a folder "include-static" besides "include" with a script which generates the files in question and places them there:

File: build.sh
#!/usr/bin/bash

# Generates the files version.h and float-version.h
# This script should be run before a new release

mkdir -p tmp
cd tmp
cmake ../../include
cd ..
cp tmp/version.h tmp/float-version.h .
rm -fr tmp

This directory would be added to git. The script should be called whenever a new version is released or can be added as a git hook

The trouble is that the previous arrangement was problematic and it would be unfortunate to go back to it. I would prefer if we can find another solution.  CMake keeps everything displaying the right versions. In the past, we often got versions wrong, or forgot to update stuff after releases. 

Again it's one of those things that help
us maintain the software. Since we are very under stress at the moment (and I don't see anyone volunteering to keep Csound maintained and released), I prefer if we simplified rather than complicated things. 

How do you manage with float-version.h? That needs to be generated too.

Since the auto-generation of float-version was put in place (I think this was brought in by Felipe and Steven), the principle seems to be that the headers in the repo are not designed to be used directly, they need to be installed. It certainly helps us keep things correctly in sync. It tripped me up to start with but then I realised that I needed to work with installed headers. 

Certainly if we put a static version in the repo, it will end up out of sync because I'm sure we'll forget. So it's either the old way or some form of auto generation, but a combination of the two is sure trouble. It may work for API clients though, to have their own static version header locally (as some do for float-version, but that's probably simpler too).

Let's hear suggestions.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 23 Dec 2021, at 13:00, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

The problem is that a complete build environment is needed just to have access to the csound headers. Particularly in a ci environment (like github actions) this means that instead of just having csound as a submodule we need to have everything needed for cmake to actually configure the csound project without errors and generate the .h files. Besides this, as per the nature of how cmake works inside another cmake project, it can be tricky to run the cmake script in csound when being included as submodule.

I would be really thankful for a static version.

Best regards,

Eduardo

On 23.12.21 12:51, Victor Lazzarini wrote:
I made that change because we kept getting versions wrong in releases and etc. It seems to do what we need, so I would prefer if we kept it. We then set the version in one place only and do not need to keep going to change the header file.

This works in the same way as the float-version.h auto generation.

The problem with keeping a static header is that it will eventually trip us. So reverting to the old way of doing things is preferred in that case.

Maybe we can work out a solution for CsoundQT that does not involve reverting to static version headers?

Is this a problem for Cabbage too?

Prof. Victor Lazzarini
Maynooth University
Ireland

On 23 Dec 2021, at 06:11, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

Hi,

there was a "recent" change
(https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fcommit%2Fa6a17c5550f06c9323d02c1fcc0b09c94b5a7d63%23diff-cbb69e8a67514ac4c02765caf1ee81f4d088a3aaf6d7be1892513d2aefb70009&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce47135c4e26048d08ef408d9c6141112%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637758612243589531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6N6FucSqV17w4xfcxSeEid8bD%2BY8nx%2B4du2vgJajdyY%3D&reserved=0)
by which include/version.h is autogenerated by cmake. This breaks lots
of build actions by plugins and csoundqt, which would include csound as
a submodule and add its include dir in their own cmake scripts in order
to build without needing to have csound (and all its dependencies)
installed. Is there any chance that this change can be reverted, or the
generated version.h included in the tree?

Thanks!

Eduardo

While I recognize the problem/inconvenience from the consuming side, I
don't think the solution is to handle it on Csound's side via
pre-written headers.  Could you inform a little more why you are using
Csound as a submodule?  I would have expected that any dependency for
a project be done based on a built-dependency or if relying on source
that one would expect to build the source or directly include the
source as part of the project and take on the responsibilities
required to use the source as designed (i.e., configure the headers
yourself).  Also, do you need a specific version of csound or is the
latest stable sufficient?

Perhaps we would be better served if we work on ensuring there's an up
to date built-dependency that can be installed easily in CI systems
(i.e., post debs somewhere that can be added to apt source list, apt
install; add csound to choco; etc.). It's more work but I think a
bigger payoff if we sort that out.  If that'd solve the problem, I'd
propose we schedule a virtual meetup sometime in the first week of
January where we just sprint and get it done.

On Thu, Dec 23, 2021 at 3:09 PM Eduardo Moguillansky
 wrote:
>
> I don't see a solution which solves this and is simple enough not to become a burden of itself. A viable middle ground would be to include a static version of the includes in some other directory as a part of the release steps. Any projects needing such static includes can simply add that directory to their search path. I can send a PR but it would amount to creating a folder "include-static" besides "include" with a script which generates the files in question and places them there:
>
> File: build.sh
> #!/usr/bin/bash
>
> # Generates the files version.h and float-version.h
> # This script should be run before a new release
>
> mkdir -p tmp
> cd tmp
> cmake ../../include
> cd ..
> cp tmp/version.h tmp/float-version.h .
> rm -fr tmp
>
> This directory would be added to git. The script should be called whenever a new version is released or can be added as a git hook
>
>
> On 23.12.21 17:38, Victor Lazzarini wrote:
>
> The trouble is that the previous arrangement was problematic and it would be unfortunate to go back to it. I would prefer if we can find another solution.  CMake keeps everything displaying the right versions. In the past, we often got versions wrong, or forgot to update stuff after releases.
>
> Again it's one of those things that help
> us maintain the software. Since we are very under stress at the moment (and I don't see anyone volunteering to keep Csound maintained and released), I prefer if we simplified rather than complicated things.
>
> How do you manage with float-version.h? That needs to be generated too.
>
> Since the auto-generation of float-version was put in place (I think this was brought in by Felipe and Steven), the principle seems to be that the headers in the repo are not designed to be used directly, they need to be installed. It certainly helps us keep things correctly in sync. It tripped me up to start with but then I realised that I needed to work with installed headers.
>
> Certainly if we put a static version in the repo, it will end up out of sync because I'm sure we'll forget. So it's either the old way or some form of auto generation, but a combination of the two is sure trouble. It may work for API clients though, to have their own static version header locally (as some do for float-version, but that's probably simpler too).
>
> Let's hear suggestions.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On 23 Dec 2021, at 13:00, Eduardo Moguillansky  wrote:
>
> The problem is that a complete build environment is needed just to have access to the csound headers. Particularly in a ci environment (like github actions) this means that instead of just having csound as a submodule we need to have everything needed for cmake to actually configure the csound project without errors and generate the .h files. Besides this, as per the nature of how cmake works inside another cmake project, it can be tricky to run the cmake script in csound when being included as submodule.
>
> I would be really thankful for a static version.
>
> Best regards,
>
> Eduardo
>
>
> On 23.12.21 12:51, Victor Lazzarini wrote:
> I made that change because we kept getting versions wrong in releases and etc. It seems to do what we need, so I would prefer if we kept it. We then set the version in one place only and do not need to keep going to change the header file.
>
> This works in the same way as the float-version.h auto generation.
>
> The problem with keeping a static header is that it will eventually trip us. So reverting to the old way of doing things is preferred in that case.
>
> Maybe we can work out a solution for CsoundQT that does not involve reverting to static version headers?
>
> Is this a problem for Cabbage too?
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On 23 Dec 2021, at 06:11, Eduardo Moguillansky  wrote:
>
> *Warning*
>
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>
> Hi,
>
> there was a "recent" change
> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fcommit%2Fa6a17c5550f06c9323d02c1fcc0b09c94b5a7d63%23diff-cbb69e8a67514ac4c02765caf1ee81f4d088a3aaf6d7be1892513d2aefb70009&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ce47135c4e26048d08ef408d9c6141112%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637758612243589531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6N6FucSqV17w4xfcxSeEid8bD%2BY8nx%2B4du2vgJajdyY%3D&reserved=0)
> by which include/version.h is autogenerated by cmake. This breaks lots
> of build actions by plugins and csoundqt, which would include csound as
> a submodule and add its include dir in their own cmake scripts in order
> to build without needing to have csound (and all its dependencies)
> installed. Is there any chance that this change can be reverted, or the
> generated version.h included in the tree?
>
> Thanks!
>
> Eduardo

Good idea to meet. Let's organise that.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 24 Dec 2021, at 16:25, Steven Yi  wrote:
> 
> While I recognize the problem/inconvenience from the consuming side, I
> don't think the solution is to handle it on Csound's side via
> pre-written headers.  Could you inform a little more why you are using
> Csound as a submodule?  I would have expected that any dependency for
> a project be done based on a built-dependency or if relying on source
> that one would expect to build the source or directly include the
> source as part of the project and take on the responsibilities
> required to use the source as designed (i.e., configure the headers
> yourself).  Also, do you need a specific version of csound or is the
> latest stable sufficient?
> 
> Perhaps we would be better served if we work on ensuring there's an up
> to date built-dependency that can be installed easily in CI systems
> (i.e., post debs somewhere that can be added to apt source list, apt
> install; add csound to choco; etc.). It's more work but I think a
> bigger payoff if we sort that out.  If that'd solve the problem, I'd
> propose we schedule a virtual meetup sometime in the first week of
> January where we just sprint and get it done.
> 
>> On Thu, Dec 23, 2021 at 3:09 PM Eduardo Moguillansky
>>  wrote:
>> 
>> I don't see a solution which solves this and is simple enough not to become a burden of itself. A viable middle ground would be to include a static version of the includes in some other directory as a part of the release steps. Any projects needing such static includes can simply add that directory to their search path. I can send a PR but it would amount to creating a folder "include-static" besides "include" with a script which generates the files in question and places them there:
>> 
>> File: build.sh
>> #!/usr/bin/bash
>> 
>> # Generates the files version.h and float-version.h
>> # This script should be run before a new release
>> 
>> mkdir -p tmp
>> cd tmp
>> cmake ../../include
>> cd ..
>> cp tmp/version.h tmp/float-version.h .
>> rm -fr tmp
>> 
>> This directory would be added to git. The script should be called whenever a new version is released or can be added as a git hook
>> 
>> 
>> On 23.12.21 17:38, Victor Lazzarini wrote:
>> 
>> The trouble is that the previous arrangement was problematic and it would be unfortunate to go back to it. I would prefer if we can find another solution.  CMake keeps everything displaying the right versions. In the past, we often got versions wrong, or forgot to update stuff after releases.
>> 
>> Again it's one of those things that help
>> us maintain the software. Since we are very under stress at the moment (and I don't see anyone volunteering to keep Csound maintained and released), I prefer if we simplified rather than complicated things.
>> 
>> How do you manage with float-version.h? That needs to be generated too.
>> 
>> Since the auto-generation of float-version was put in place (I think this was brought in by Felipe and Steven), the principle seems to be that the headers in the repo are not designed to be used directly, they need to be installed. It certainly helps us keep things correctly in sync. It tripped me up to start with but then I realised that I needed to work with installed headers.
>> 
>> Certainly if we put a static version in the repo, it will end up out of sync because I'm sure we'll forget. So it's either the old way or some form of auto generation, but a combination of the two is sure trouble. It may work for API clients though, to have their own static version header locally (as some do for float-version, but that's probably simpler too).
>> 
>> Let's hear suggestions.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>> On 23 Dec 2021, at 13:00, Eduardo Moguillansky  wrote:
>> 
>> The problem is that a complete build environment is needed just to have access to the csound headers. Particularly in a ci environment (like github actions) this means that instead of just having csound as a submodule we need to have everything needed for cmake to actually configure the csound project without errors and generate the .h files. Besides this, as per the nature of how cmake works inside another cmake project, it can be tricky to run the cmake script in csound when being included as submodule.
>> 
>> I would be really thankful for a static version.
>> 
>> Best regards,
>> 
>> Eduardo
>> 
>> 
>> On 23.12.21 12:51, Victor Lazzarini wrote:
>> I made that change because we kept getting versions wrong in releases and etc. It seems to do what we need, so I would prefer if we kept it. We then set the version in one place only and do not need to keep going to change the header file.
>> 
>> This works in the same way as the float-version.h auto generation.
>> 
>> The problem with keeping a static header is that it will eventually trip us. So reverting to the old way of doing things is preferred in that case.
>> 
>> Maybe we can work out a solution for CsoundQT that does not involve reverting to static version headers?
>> 
>> Is this a problem for Cabbage too?
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>> On 23 Dec 2021, at 06:11, Eduardo Moguillansky  wrote:
>> 
>> *Warning*
>> 
>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> 
>> Hi,
>> 
>> there was a "recent" change
>> (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fcommit%2Fa6a17c5550f06c9323d02c1fcc0b09c94b5a7d63%23diff-cbb69e8a67514ac4c02765caf1ee81f4d088a3aaf6d7be1892513d2aefb70009&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Ca1160b9e595e42dbd15708d9c6f9e5d2%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637759599513477594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kQY%2BnFkAHy3NIpAXnTjnJDOTw%2FbFAfK2vyc2U2LkC8A%3D&reserved=0)
>> by which include/version.h is autogenerated by cmake. This breaks lots
>> of build actions by plugins and csoundqt, which would include csound as
>> a submodule and add its include dir in their own cmake scripts in order
>> to build without needing to have csound (and all its dependencies)
>> installed. Is there any chance that this change can be reverted, or the
>> generated version.h included in the tree?
>> 
>> Thanks!
>> 
>> Eduardo