Re: build customizability

[brainchild <ericlevy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3131 bytes --]

Thank you for the recent comments. Let me respond to all in one message, as 
they overlap in scope.

I address a few issues, in sequence, as follows:

   1. *Markdown reader dependencies: *I now understand the conflict. In 
   many potential deployment scenarios, for example applications that employ 
   Markdown source, the embedding of snippets in some target language is 
   unlikely to be needed, except perhaps as narrowly allowed for equations. 
   Thus, if this functionality were entirely enclosed in extensions, and if 
   those extensions could be disabled in the build, then in principle it may 
   be possible to realize the benefit of removing the dependencies on the 
   parsers. I understand that it would require restructuring the code.
   2. *Evaluating size of library dependencies: *If, as Albert says, only a 
   handful of packages may be eliminated from the build, even in the case that 
   only a few readers or writers were needed, and if the size of these 
   packages is not vastly greater than the size of others, then clearly the 
   material benefit of eliminating certain readers and writers from the build 
   is very limited. However, I make a few notes:
      1. Is the reason that most dependencies would remain even after 
      removing most of the readers and writers that these dependencies are needed 
      separately by all the readers and writers, or rather that they are needed 
      by the core application? In the latter case, perhaps some of the core 
      functionality not needed in basic uses, again at least in principle, can be 
      separated.
      2. My earlier question directed mostly at the difficulty of 
      determining confidently the complete set of dependencies to remove, without 
      invoking a formal solution such as graph traversal, compared to the 
      possibility of missing a set in an informal assessment.
      3. *Footprint of Runtime System:* No, I was not specifically aware of 
   the size of the Runtime System. I am having difficulty finding a clear 
   indication of how much size it adds to the final executable size, but 
   estimates that seem to recur are in the 10-15 megabyte range. If these 
   estimates are accurate, then it would be impossible to achieve vastly 
   smaller sizes, obviously, but this information alone is not sufficient to 
   conclude the impossibility of achieving significant savings through methods 
   already discussed. Also, I am seeing some hints that a GHC backend for LLVM 
   is available that makes possible much more optimal build results. 
   Unfortunately, I have not found any quantitative assessment of these 
   savings, nor can I find any active project maintaining this interface.
   

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/f9fd9cfe-e03f-45d3-bcb5-07267c28e565%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3406 bytes --]