In the long term, checking the generated C++ code into the repository in a
"bootstrap" or "cache" folder of some sort and switch alll the tools to be
written in Felix (especially flxg) is the way to go.
On Thu, Jan 17, 2013 at 2:07 AM, john skaller <skal...@users.sourceforge.net
> wrote:
> No, I have no plan to replace Ocaml yet :)
>
> Felix currently compiles using flx. In turn, flx invokes flxg (Ocaml)
> and flx_pkgconfig .. which is written in Felix. This creates a circularity.
>
> This circularity is resolved as follow currently:
>
> flx_pkgconfig is built first, using hand crafted Python
> script to replace what flx would do. This script is split between
> a core part of fbuild (which supports Felix directly) and part
> of the Felix build system extension.
>
> The script emulates what flx_pkgconfig would do by doing
> nothing. Instead, we note that the one thing flx_pkgconfig does
> that is mandatory for C++ compilation is that it maps abstract
> resources to #include files.
>
> But, I know what those files are, so the repository directly includes
> the output that flx_pkgconfig would produce if it existed and was
> invoked when compiling itself.
>
> Now, I am thinking to write more tools in Felix that become
> part of the compilation and build process. Several of these
> already exist, but they're only required after they've been built
> by the normal build method: these include flx_cp, which is a
> sane variant of the unix cp command. flx_cp uses Perl
> regexps and replacement syntax to copy files (as well as
> guaranteeing no clobbering).
>
> However there is another tool, flx_tangle, which already exists,
> and is used to verify that the tutorials contain working code,
> by extracting that code, subsequently we run the code
> and check its output.
>
> Flx_tangle is a mini-literate programming too. It processes
> a document in fdoc format which can be displayed as
> "documented code" by the webserver, and, with flx_tangle,
> it can also be compiled.
>
> This works well now: the new tutorial text is checked this
> way automatically by "make gendoc".
>
> Now why am I telling you all this? Because I want to put the
> whole library into this format!
>
> At present some tools can document the library by extracting
> special //$ comments. This is fine for an index, especially as it
> hyperlinks to the actual code.
>
> But it is useless for *explaining* how the library module works.
> I do NOT want to explain every library module in a separate
> document: it is impossible to keep the documentation accurate.
> It requires repeating at least the types and signatures of the
> library in the docs. No way Jose! Not enough resources for that.
>
> Now I am not writing this to argue about literate programming
> (there are separate concerns here, worth discussing).
>
> The issue is: how do we extract the Felix source code
> from the Fdoc sources with flx_tangle to create the standard
> library, when we need the standard lbrary to compile flx_tangle
> in the first place?
>
> METHOD 1
>
> The first method is simple and I am already using this method
> to support generated documentation such as the library index.
> With that method I run "make gendoc" and the web pages get
> generated from the library sources. The generated pages are
> tracked by git in the repository, so I just commit them.
>
> When a user gets Felix from git, there's no need to generate
> the docs, the job is already done. The big negative here is that
> these are dependent sources. They're NOT editable because any
> changes you make will be clobbered by the next gendoc.
> I wish there were a way to specify that in git. In the generated
> code we might add "warning, generated do not edit".
>
> This method will work for the library too. The main caveat is that
> with a mixture of wrapped and non-wrapped library code,
> any contributor will need to be careful to edit the original
> independent source. [That's a BIG negative of literate
> programming, because IDE's and editors are not good at
> handling the mixed format of LP sources]
>
> METHOD 2
>
> This is an advanced version of method 1, in which we seek
> to extract the library code from the original source (LP code)
> without needing to commit the product files (actual Felix code)
> to the repository.
>
> We still have to cheat the repository by committing generated
> code, but we move one level up.
>
> What we do is we commit the C++ generated by Felix
> for the core tools: flx_tangle, flx, flx_pkgconfig, to the repository.
> We then use C++ to build these tools. If we want, we can
> use these bootstrapped tools to rebuild themselves
> from Felix sources (or, indeed, from LP wrapped versions
> of them).
>
> So, one aim for the build system in the near future is to ensure
> we can generated "packaged up" versions of tools as C++
> source code that can easily be built. Possibly we just add
> a Makefile to the directory containing the generated sources.
>
> Doing this has another advantage. If you don't want your boss
> to know you're using Felix, just supply the C++. Well, that's
> a joke but the real use is to generate tools conforming
> to common package manager specifications.
>
> Then Felix can be used to create tools ready to package for
> ArchLinux, Debian, Ubuntu, Redhat, or whatever (in fact
> with a bit more work "flx" can be taught how to generate
> the package scripts).
>
> This is a major advantage of Felix over some other systems.
> Bootstrapping on a new platform should be a breeze, because
> in principle, you can just generate targeted C++ code, ship
> to the new platform, and compile.
>
> IMPORTANT USE
>
> There is a really important use of this: if the build system
> is rewritten in Felix, how do you build Felix without Felix??
>
> And now we have an answer: all you need is C++
> and an ordinary kind of bootstrap build tool (like make
> or even fbuild).
>
> So in the future, I may write some build tools and there
> will be a bit of duplication and confusion during the
> rephasing.
>
> --
> john skaller
> skal...@users.sourceforge.net
> http://felix-lang.org
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Felix Language" group.
> To post to this group, send email to felix-langu...@googlegroups.com.
> To unsubscribe from this group, send email to
> felix-language+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/felix-language?hl=en.
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
