[Packaging][C++] gdb integration is not compatible with conda packaging #34670

Closed
#34672
Closed
[Packaging][C++] gdb integration is not compatible with conda packaging#34670
#34672
Assignees
kou
Labels
Component: PackagingType: bug
Milestone
12.0.0

Description

@h-vetinari
h-vetinari
opened on Mar 22, 2023

Describe the bug, including details regarding any error messages, version, and platform.

gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using

arrow/cpp/src/arrow/CMakeLists.txt

Lines 674 to 675 in 1ba4425

set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR
"${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}")

However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.

The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).

@kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.

Component(s)

Packaging

Metadata

Metadata

Assignees

Labels

Component: PackagingType: bug

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
     blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

    Skip to content
    [Packaging][C++] gdb integration is not compatible with conda packaging #34670
    Closed
    #34672
    Closed
    [Packaging][C++] gdb integration is not compatible with conda packaging#34670
    #34672
    Assignees
    kou
    Labels
    Component: PackagingType: bug
    Milestone
    12.0.0
    Description
    @h-vetinari
    h-vetinari
    opened on Mar 22, 2023
    Describe the bug, including details regarding any error messages, version, and platform.
    gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using
    arrow/cpp/src/arrow/CMakeLists.txt
    
Lines 674 to 675
in
1ba4425
    set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR 
    "${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}") 
    However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.
    The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).
    @kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.
    Component(s)
    Packaging
    Metadata
    Metadata
    Assignees
    Labels
    Component: PackagingType: bug
    Type
    No type
    Projects
    No projects
      Milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

      Skip to content
      [Packaging][C++] gdb integration is not compatible with conda packaging #34670
      Closed
      #34672
      Closed
      [Packaging][C++] gdb integration is not compatible with conda packaging#34670
      #34672
      Assignees
      kou
      Labels
      Component: PackagingType: bug
      Milestone
      12.0.0
      Description
      @h-vetinari
      h-vetinari
      opened on Mar 22, 2023
      Describe the bug, including details regarding any error messages, version, and platform.
      gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using
      arrow/cpp/src/arrow/CMakeLists.txt
      
Lines 674 to 675
in
1ba4425
      set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR 
      "${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}") 
      However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.
      The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).
      @kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.
      Component(s)
      Packaging
      Metadata
      Metadata
      Assignees
      Labels
      Component: PackagingType: bug
      Type
      No type
      Projects
      No projects
        Milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

        Skip to content
        [Packaging][C++] gdb integration is not compatible with conda packaging #34670
        Closed
        #34672
        Closed
        [Packaging][C++] gdb integration is not compatible with conda packaging#34670
        #34672
        Assignees
        kou
        Labels
        Component: PackagingType: bug
        Milestone
        12.0.0
        Description
        @h-vetinari
        h-vetinari
        opened on Mar 22, 2023
        Describe the bug, including details regarding any error messages, version, and platform.
        gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using
        arrow/cpp/src/arrow/CMakeLists.txt
        
Lines 674 to 675
in
1ba4425
        set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR 
        "${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}") 
        However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.
        The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).
        @kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.
        Component(s)
        Packaging
        Metadata
        Metadata
        Assignees
        Labels
        Component: PackagingType: bug
        Type
        No type
        Projects
        No projects
          Milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

          Skip to content
          [Packaging][C++] gdb integration is not compatible with conda packaging #34670
          Closed
          #34672
          Closed
          [Packaging][C++] gdb integration is not compatible with conda packaging#34670
          #34672
          Assignees
          kou
          Labels
          Component: PackagingType: bug
          Milestone
          12.0.0
          Description
          @h-vetinari
          h-vetinari
          opened on Mar 22, 2023
          Describe the bug, including details regarding any error messages, version, and platform.
          gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using
          arrow/cpp/src/arrow/CMakeLists.txt
          
Lines 674 to 675
in
1ba4425
          set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR 
          "${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}") 
          However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.
          The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).
          @kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.
          Component(s)
          Packaging
          Metadata
          Metadata
          Assignees
          Labels
          Component: PackagingType: bug
          Type
          No type
          Projects
          No projects
            Milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

            Skip to content
            [Packaging][C++] gdb integration is not compatible with conda packaging #34670
            Closed
            #34672
            Closed
            [Packaging][C++] gdb integration is not compatible with conda packaging#34670
            #34672
            Assignees
            kou
            Labels
            Component: PackagingType: bug
            Milestone
            12.0.0
            Description
            @h-vetinari
            h-vetinari
            opened on Mar 22, 2023
            Describe the bug, including details regarding any error messages, version, and platform.
            gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using
            arrow/cpp/src/arrow/CMakeLists.txt
            
Lines 674 to 675
in
1ba4425
            set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR 
            "${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}") 
            However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.
            The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).
            @kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.
            Component(s)
            Packaging
            Metadata
            Metadata
            Assignees
            Labels
            Component: PackagingType: bug
            Type
            No type
            Projects
            No projects
              Milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

              Skip to content
              [Packaging][C++] gdb integration is not compatible with conda packaging #34670
              Closed
              #34672
              Closed
              [Packaging][C++] gdb integration is not compatible with conda packaging#34670
              #34672
              Assignees
              kou
              Labels
              Component: PackagingType: bug
              Milestone
              12.0.0
              Description
              @h-vetinari
              h-vetinari
              opened on Mar 22, 2023
              Describe the bug, including details regarding any error messages, version, and platform.
              gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using
              arrow/cpp/src/arrow/CMakeLists.txt
              
Lines 674 to 675
in
1ba4425
              set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR 
              "${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}") 
              However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.
              The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).
              @kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.
              Component(s)
              Packaging
              Metadata
              Metadata
              Assignees
              Labels
              Component: PackagingType: bug
              Type
              No type
              Projects
              No projects
                Milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions
                
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

                Skip to content
                [Packaging][C++] gdb integration is not compatible with conda packaging #34670
                Closed
                #34672
                Closed
                [Packaging][C++] gdb integration is not compatible with conda packaging#34670
                #34672
                Assignees
                kou
                Labels
                Component: PackagingType: bug
                Milestone
                12.0.0
                Description
                @h-vetinari
                h-vetinari
                opened on Mar 22, 2023
                Describe the bug, including details regarding any error messages, version, and platform.
                gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using
                arrow/cpp/src/arrow/CMakeLists.txt
                
Lines 674 to 675
in
1ba4425
                set(ARROW_GDB_AUTO_LOAD_LIBARROW_GDB_DIR 
                "${ARROW_GDB_AUTO_LOAD_DIR}/${CMAKE_INSTALL_FULL_LIBDIR}") 
                However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of CMAKE_INSTALL_FULL_LIBDIR means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to problems due to path length.
                The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a patch and an activation script (which will always execute upon entering/activating an environment).
                @kou asked me in #34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work.
                Component(s)
                Packaging
                Metadata
                Metadata
                Assignees
                Labels
                Component: PackagingType: bug
                Type
                No type
                Projects
                No projects
                  Milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions