Re: [open-cobol-list] Splitting files by platform, cobc performance survey

[Brian Tiffin]

1) yeah not so much.  You end up chasing your tail through directories
looking for the right file instead of tracing though conditional
compiles with a single source.

2) Umm, for now, autotools is the way to go.  Yes it is voodoo, but
still likely the best choice for cross platform developments.  There
are other build systems, but they all end up in voodoo land once they
cover the same number of bases that autotools covers.  If we get
accepted as a GNU/FSF project, autotools is one of the mandates for
the source structure.

3) Look to Vincent's accounting system for a package with a higher
line count. http://sourceforge.net/projects/acas/

4) Agree.  There are good efforts getting VBISAM into the mix, and
Frank assisted with the extfh build options a while back.  To be
honest, if I ever get the time, I'd like to try and replace libdb with
Tokyo Cabinet, but for the now, I think we should focus on Trevor's
VBISAM.  It works well, but could use a little work to up its
reliability on the edge cases.  Or along with the GNU proposal, we
might want to ask Oracle for an exemption mentioning that the ProCOB
processor works with OpenCOBOL and more adoption of OC might be a path
to up sales of Oracle?

Cheers,
Brian

On 9/12/13, Patrick <address@hidden> wrote:
> Hi Everyone, Hi Joe
>
> I wish I could answer your post from today but I just don't know
> anything about the CE source.
>
> I wanted to mention that Brian Tiffin will likely have valuable feedback
> but he may be be tied up at the moment, we exchanged emails briefly a
> few days ago. Please wait for his answer, it may be some time.
>
> I didn't want to high-jack Joe's thread so I created another one, even
> though it is similar, in some respects.
>
> 1)
>
>
> I find the libcob source a bit hard to read. There is a lot of platform
> specific code within single files, adjusted with lots of compiler
> directives.
>
> Would it be a good idea to split them off into other files, named by
> platform,  to increase readability ? I would be happy to try and help
> with this, if it was deemed to be a good idea.
>
>
> 2)
>
> autotools is surely a powerful thing but I have yet to read about anyone
> that "enjoys" autotools. In fact, what seems to be repeated over and
> over again is autotools is hell. Is there another build system that
> might be more suitable? I have been trying to read about developing with
> autotools so that I can start contributing little pieces of code to the
> project. I understand the basics but there seems to be so many pitfalls
> with it and I am still afraid of falling into a hole. We really need
> more developers, if there was simpler tools that might help lower the
> barrier to entry?
>
> 3)
>
> All of my Cobol programs are still small. Has anyone compiled a large
> codebase of let's say 50-100K lines of code? I am wondering how cobc
> performs with larger projects. If speed just isn't an issue, maybe we
> could have discussions about how to make cobc easier to get involved
> with, perhaps there are other languages that could also be used such as
> Cobol itself. There is no runtime penalty for a slower compiler.
>
> 4)
>
> I don't really know so much about libdb, I am trying to read up on it.
> Does it have a very different purpose then let's say sqlite? It seems
> smaller and I assume faster but with Oracle changing the license and
> affecting the way we can, then in turn license our code using any
> current version of libdb, it seems like a discussion on alternatives
> might be a good thing.
>
> -Patrick
>
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>