Generate .bib file name from SRS TeX file

[njericha]

Currently, the bib file name is a hard coded string in Config.hs and used in two places.

--Config.hs line 89-90
bibFname :: String
bibFname = "bibfile"

--TeX/Preamble.hs line 75
addDef Bibliography  = command "bibliography" bibFname

--TeX/Print.hs line 545-549
makeBib bib = spec $ S ("\\begin{filecontents*}{"++bibFname++".bib}\n") :+: ...

When TeX is run, it generates this file in the same directory. Problems arise when multiple TeX files are run after each other because other examples can overwrite this file. Ideally, the file name will be chosen to match that of the TeX file. Right now, there is no easy way of getting the name of the TeX file, to these functions.

[szymczdm]

When TeX is run, it generates this file in the same directory.

I can't find any reference to this bit in the code (ie. no new file being created), but it really should be created at some point. Getting the file name should be easy (the function which takes in our "recipes" should take care of this and pass it along instead of baking it into the back-end).

[peter-michalski]

@JacquesCarette When time permits, could I please get a quick explanation of what is meant/referenced by @szymczdm's comment "the function which takes in our "recipes" should take care of this and pass it along instead of baking it into the back-end"? I am not finding any mention of recipes or recipe in the code. Does this function already exist and hold the required file name, or is it a concept?

Is there and will there continue to be just one bibfile instance per example (NoPCM, HGHC..)? If so the bibfile name can be a generic name for the example?

[smiths]

@peter-michalski, "recipes" is terminology that we use, but it isn't explicit in the code. When we write code in DSLs to explain how we want to transform the knowledge into some artifact, like a requirements document, we are saying we are writing a "recipe." We are using this as an analogy to a cook book. 😄

Yes, there would be one bibfile instance per example. I think the idea is that the bibfile name would be generated to be a unique name for the particular example.

[JacquesCarette]

Exactly.

[balacij]

The OP appears to be outdated in the operational sense (it assumes examples are run in the same working directory, but we currently separate them). I also don't have any real issue with this. Further, I believe this is not quite how .bib generation works anymore? It would probably be nice now to use multi-file generation that @BilalM04 has prepared (that way, we can further push towards building more multi-file generation infrastructure too).

@BilalM04 Do you think you could look into this ticket and what needs to be done, please?

[BilalM04]

From looking at the TeX printer and the generated TeX files, the bib is specified within the main TeX file (Example_SRS.tex). The bib is enclosed in \begin{filecontents*}{bibfile.bib}, thus when compiled, it creates a .bib file with the bibliography contents from the main TeX file.

I believe the original issue was because all the example TeX files were generated into the same directory, with the exact same name for the .bib file. As a result, compiling the different examples would override the existing .bib file. As a solution, the OP suggested having example specific names for the .bib files.

Since now the different examples are separated into their own directories, the issue of the filenames clashing is no longer present. How should we proceed @balacij?

[smiths]

Good summary @BilalM04. My interpretation is that we can close this issue, but let's see what @balacij says.

[JacquesCarette]

We might want to make the generation of .bib separate, now that we can.

[balacij]

Thank you, @BilalM04 😄

Do you know how much effort it would require to move the bib content to a separate file? It doesn't necessarily need to be named Example.bib or anything of the sorts, but references.bib or something of the sorts would be good. If it isn't a lot of effort, I think it's worth it to do, but if it's anything more than an hour or so, it probably isn't, and we could just close the ticket.

[BilalM04]

How multi-file generation works for mdBook is that at the level of drasil-printers it takes a Document and converts it to a Project by extracting all sections, sub-sections, and sub-sub-sections, into their own sections/files in order to support the needs of mdBook. It would not be very friendly for extracting one specific section, such as the bib. We can always create another function that extracts just the bib, but that would require a lot of hacky code.

Drasil is still not very friendly with multi-file generation, as from when it's declared in drasil-example to when it reaches drasil-printers, an SRS is assumed to be a single Document.

Overall, moving the bib content to a separate file would require considerable effort, as the current mdBook setup addresses the specific issue of extracting all sections into separate files. Rather than pursuing this approach, I believe we should first develop a better design for multi-file generation before proceeding with extracting the bib content.

[balacij]

Sounds good to me. Thank you, @BilalM04. In that case, when we have a better resolution to #3796, we can revisit this.