考虑代码结构整理
xiawenq opened this issue · 9 comments
是否考虑让库支持cmake管理，同时重新整理下代码结构。
目前的代码结构感觉不利于让这个仓库作为子模块嵌入到其他工程中，特别是没办法从makefile中生成动态或者静态库文件。能够方便的引用头文件，链接库即可使用这个库。
挺好的想法，请具体说下你的改进方案吧
纯嵌入式工程我已经很久没做了，这块的改动我可能没什么好的建议，但是如果嵌入式工程也可以转用CMAKE进行管理的话，下面的改进我觉得应该也可以用到嵌入式工程中去。
对于通用的linux下面的工程模块来说，按照我个人粗浅的理解。下面有些东西可以改进：
1、/easylogger目录下面，plugins目录和port目录整个移到上一层。且easylogger/inc目录下面去除elog_cfg.h，只保留elog.h，并且对于elog_cfg.h中一些必备的宏定义，在elog.h中使用ifndef指令进行判断，在外部没有指定这些宏定义的情况下，定义最简的默认宏定义值。如此来看，/easylogger目录下面，就是最简的核心日志库源代码。可以单独对这些代码进行编译，生成核心库。
2、部分宏定义是字符串类型的定义，是否可以使用<extern const char*>指令定义替代，对于这部分的宏定义来说，灵活度增加了，应该也不会产生什么副作用，某些时候可以减少宏定义扩展带来的代码膨胀。
3、把/demo目录下的东西移到/port目录中，里面已经实现了各个平台的最基础的移植代码，可以和核心库一起链接生成各个平台下可以真正使用的日志库。
这样，外部只需要包含/easylogger/inc/elog.h头文件，和/demo下各平台生成的日志库文件，就可以正常工作。
这确实是个不错的办法，可以作为 EasyLogger V3.0 的 Roadmap 了，你有空先做个雏形版本不
可以，我这边可以先做。
你可以先开一个新的分支，我到时候做完了提交到那个分支上去，这样未完成内容不会影响到主分支。
不敢不敢，只是把文件调换个位置，整成cmake工程而已。
抱歉，我看的深入了才发现这里面宏定义用的有点多，我打算把easylogger目录下面 elog.c elog_async.c elog_buf.c elog_utils.c里面变量和函数里用到的宏定义，全都改成指针变量和可配置flag变量判断是否执行代码。
不然好像简化不了。。。，所以对于嵌入式ram、flash资源紧张的使用场景来看，好像flash使用量会膨胀的比较厉害。。。
是的，如果都改成 flag 判断，资源占用也会有所增长
还有其他的方法没？或者只考虑 linux 的场景，特殊优化一下？
我没想到好办法，可能针对非嵌入式单独做一版这种不用宏定义的，会好点- -。。。
先做做看