小编kbl*_*uck的帖子

想象一下,您希望在Python中开发一个非平凡的最终用户桌面(而不是Web)应用程序.构建项目文件夹层次结构的最佳方法是什么？

理想的功能是易于维护,IDE友好,适用于源代码控制分支/合并,以及易于生成安装包.

特别是:

1. 你把源头放在哪里？
2. 你把应用程序启动脚本放在哪里？
3. 你把IDE项目放在哪里？
4. 你在哪里进行单位/验收测试？
5. 你在哪里放置非Python数据,如配置文件？
6. 你在哪里为pyd/so二进制扩展模块放置非Python源代码如C++？

我有一个共享库,我希望链接可执行文件与使用GCC.共享库具有非标准名称,而不是libNAME.so形式,因此我不能使用通常的-l选项.(它恰好也是一个Python扩展,因此没有'lib'前缀.)

我能够将库文件的路径直接传递给链接命令行,但这会导致库路径硬编码到可执行文件中.

例如:

g++ -o build/bin/myapp build/bin/_mylib.so

有没有办法链接到这个库而不会导致路径被硬编码到可执行文件中？

我正在尝试将包含特殊字符串$ ORIGIN的RPATH链接到使用GCC和Code :: Blocks IDE构建的可执行文件中.我指定了

-Wl,-R$ORIGIN

在项目的链接器选项中,但输出到GCC的命令行是错误的(为了清楚起见剥离):

g++ -Wl,-R

为Code :: Blocks指定此参数的正确方法是什么？

在Win32上的C++中:

假设我有一个带有头文件的DLL,它声明了一个类.DLL导出一些获取指向该类实例的指针/引用的方法,例如工厂函数.

我是否正确认为如果只在其实例上调用虚函数或内联函数,则不必使用__declspec将该类标记为导出？

相反,如果想要调用非虚拟成员函数,是否有必要导出类声明？

是否有一种可靠的方法来为ISO标准C中的固定8,16,32和64位长度的整数类型声明typedef？

当我说ISO标准C时,我的意思是:

• ISO C89/C90,而不是C99.
• 没有在ISO标准中定义的标头.
• 没有在ISO标准中定义的预处理器符号.
• ISO标准中未指定类型大小的假设.
• 没有专有供应商符号.

我在StackOverflow中看到了与此类似的其他问题,但没有答案尚未违反上述约束之一.如果不诉诸平台符号,我不确定是否可行.

是否有可能使可执行文件看起来像Linux上的只读文件,这样打开"文件"进行读取实际执行文件并使其stdout可用于读取,就好像它是"文件"中的数据一样？任何知道如何打开文件进行阅读的程序都应该可以打开它,例如'cat'.