Csound Csound-dev Csound-tekno Search About

[Csnd-dev] default search location of OPCODE7DIR64

Date2022-12-29 19:26
FromHlöðver Sigurðsson
Subject[Csnd-dev] default search location of OPCODE7DIR64
I'm just wondering out loud, does it make sense to set the default value of OPCODE7DIR64 to the path of the binary that created the process. It's just that, as I keep rebuilding csound into the build folder, it will default to the global OPCODE7DIR64 path and not for the newly built assets. It's easy to fix with an env-var (just more terminal typing), but I feel the default behavior should be this, that the path of the csound binary, or utility binary, should start the search in the folder it's stored in. I guess if it's necessary, the search could have the hardcoded default search path as the fallback if this search isn't possible on some systems.

Date2022-12-30 01:07
FromStephen Kyne
SubjectRe: [Csnd-dev] default search location of OPCODE7DIR64
I have thought about this as well. We could possibly add a CMake pragma to add something to debug builds to enact this behaviour. It would make it easier testing full builds.

Thanks,
Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Hlöðver Sigurðsson <hlolli@GMAIL.COM>
Sent: Thursday 29 December 2022 19:26
To: CSOUND-DEV@LISTSERV.HEANET.IE <CSOUND-DEV@LISTSERV.HEANET.IE>
Subject: [Csnd-dev] default search location of OPCODE7DIR64
 
I'm just wondering out loud, does it make sense to set the default value of OPCODE7DIR64 to the path of the binary that created the process. It's just that, as I keep rebuilding csound into the build folder, it will default to the global OPCODE7DIR64 path and not for the newly built assets. It's easy to fix with an env-var (just more terminal typing), but I feel the default behavior should be this, that the path of the csound binary, or utility binary, should start the search in the folder it's stored in. I guess if it's necessary, the search could have the hardcoded default search path as the fallback if this search isn't possible on some systems.

Date2022-12-30 02:06
FromHlöðver Sigurðsson
SubjectRe: [Csnd-dev] default search location of OPCODE7DIR64
If you mean debug as in no-optimizations, that sounds good to me, but the debug mode built into csound which prints asts and pointer addresses, I don't like to use because it's too noisy imo. I also think non-technical users who build from sources would also benefit from this behavior. But I assume we'll maybe need to do some capabilities test for this, I don't know exactly which c function can find the path of the running process, but I assume that this function wont exist in wasm environments, in which case only including the hardcoded default fallback path makes sense.

On Fri, 30 Dec 2022 at 02:07, Stephen Kyne <stevek@outlook.ie> wrote:
I have thought about this as well. We could possibly add a CMake pragma to add something to debug builds to enact this behaviour. It would make it easier testing full builds.

Thanks,
Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Hlöðver Sigurðsson <hlolli@GMAIL.COM>
Sent: Thursday 29 December 2022 19:26
To: CSOUND-DEV@LISTSERV.HEANET.IE <CSOUND-DEV@LISTSERV.HEANET.IE>
Subject: [Csnd-dev] default search location of OPCODE7DIR64
 
I'm just wondering out loud, does it make sense to set the default value of OPCODE7DIR64 to the path of the binary that created the process. It's just that, as I keep rebuilding csound into the build folder, it will default to the global OPCODE7DIR64 path and not for the newly built assets. It's easy to fix with an env-var (just more terminal typing), but I feel the default behavior should be this, that the path of the csound binary, or utility binary, should start the search in the folder it's stored in. I guess if it's necessary, the search could have the hardcoded default search path as the fallback if this search isn't possible on some systems.

Date2022-12-30 02:12
FromHlöðver Sigurðsson
SubjectRe: [Csnd-dev] default search location of OPCODE7DIR64
on Linux I believe it would be
readlink ("/proc/self/exe", &path)

on OSX there's
_NSGetExecutablePath(dirNameBuffer, &path)

On Fri, 30 Dec 2022 at 03:06, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
If you mean debug as in no-optimizations, that sounds good to me, but the debug mode built into csound which prints asts and pointer addresses, I don't like to use because it's too noisy imo. I also think non-technical users who build from sources would also benefit from this behavior. But I assume we'll maybe need to do some capabilities test for this, I don't know exactly which c function can find the path of the running process, but I assume that this function wont exist in wasm environments, in which case only including the hardcoded default fallback path makes sense.

On Fri, 30 Dec 2022 at 02:07, Stephen Kyne <stevek@outlook.ie> wrote:
I have thought about this as well. We could possibly add a CMake pragma to add something to debug builds to enact this behaviour. It would make it easier testing full builds.

Thanks,
Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Hlöðver Sigurðsson <hlolli@GMAIL.COM>
Sent: Thursday 29 December 2022 19:26
To: CSOUND-DEV@LISTSERV.HEANET.IE <CSOUND-DEV@LISTSERV.HEANET.IE>
Subject: [Csnd-dev] default search location of OPCODE7DIR64
 
I'm just wondering out loud, does it make sense to set the default value of OPCODE7DIR64 to the path of the binary that created the process. It's just that, as I keep rebuilding csound into the build folder, it will default to the global OPCODE7DIR64 path and not for the newly built assets. It's easy to fix with an env-var (just more terminal typing), but I feel the default behavior should be this, that the path of the csound binary, or utility binary, should start the search in the folder it's stored in. I guess if it's necessary, the search could have the hardcoded default search path as the fallback if this search isn't possible on some systems.

Date2023-01-01 22:49
FromStephen Kyne
SubjectRe: [Csnd-dev] default search location of OPCODE7DIR64
Maybe adding a Cmake flag for it is best so if you want to avoid debug mode. 

Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Hlöðver Sigurðsson <hlolli@GMAIL.COM>
Sent: Friday 30 December 2022 02:12
To: CSOUND-DEV@LISTSERV.HEANET.IE <CSOUND-DEV@LISTSERV.HEANET.IE>
Subject: Re: [Csnd-dev] default search location of OPCODE7DIR64
 
on Linux I believe it would be
readlink ("/proc/self/exe", &path)

on OSX there's
_NSGetExecutablePath(dirNameBuffer, &path)

On Fri, 30 Dec 2022 at 03:06, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
If you mean debug as in no-optimizations, that sounds good to me, but the debug mode built into csound which prints asts and pointer addresses, I don't like to use because it's too noisy imo. I also think non-technical users who build from sources would also benefit from this behavior. But I assume we'll maybe need to do some capabilities test for this, I don't know exactly which c function can find the path of the running process, but I assume that this function wont exist in wasm environments, in which case only including the hardcoded default fallback path makes sense.

On Fri, 30 Dec 2022 at 02:07, Stephen Kyne <stevek@outlook.ie> wrote:
I have thought about this as well. We could possibly add a CMake pragma to add something to debug builds to enact this behaviour. It would make it easier testing full builds.

Thanks,
Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Hlöðver Sigurðsson <hlolli@GMAIL.COM>
Sent: Thursday 29 December 2022 19:26
To: CSOUND-DEV@LISTSERV.HEANET.IE <CSOUND-DEV@LISTSERV.HEANET.IE>
Subject: [Csnd-dev] default search location of OPCODE7DIR64
 
I'm just wondering out loud, does it make sense to set the default value of OPCODE7DIR64 to the path of the binary that created the process. It's just that, as I keep rebuilding csound into the build folder, it will default to the global OPCODE7DIR64 path and not for the newly built assets. It's easy to fix with an env-var (just more terminal typing), but I feel the default behavior should be this, that the path of the csound binary, or utility binary, should start the search in the folder it's stored in. I guess if it's necessary, the search could have the hardcoded default search path as the fallback if this search isn't possible on some systems.