Hi,

Could you please see a patch for including generated doc as external ressource and not compiled inside doxygen.

It save a few byte, improve the jquery problem and so on.

Please said if it seems appropriate.

I will add every external ressource if you think it is good.

It need more patch to be supported upstream but for a debian patch it is a good beginning.

Bastien

Hi Bastien,

Thanks for working on the embedding problem for doxygen! While I see
your patch, I am somewhat left in the dark as to what it tries to
achieve and which part of the problem it tries to solve. Please
elaborate.
 * The patch tries to move the contents of header.html.in from the
   binary to /usr/share/doxygen. Data is moved, not saved.
 * Since the header you moved, does not contain jquery, it does not
   affect the embedding of jquery at all.
 * What do you mean with "and so on"?

I suggest that before you invest additional time into polishing a patch,
you explain precisely what you are trying to achieve. I'll be happy to
help with the implementation, but as I have explained in README.jquery,
I do not see how to substantially improve the situation.

I refrain from tagging the bug - patch + moreinfo in the presumption
that you'll provide the requested information in a timely manner.

Helmut

Le 23 janv. 2014 19:09, "Helmut Grohne" <helmut@subdivi.de> a écrit :
ressource and not compiled inside doxygen.

My goal is to move the data from c file compiles to run time. Thus 1. 2. 3
or your readme.jquerry are not used for debian.

And so on means I have done for one file but I will do for all file
including png if needed.

My goal is to automatically generate a data package. After I will use
compatibilty layer of jquerry in order to replace link in generated package.

Bastien

Hi Bastien,

From my point of view it does not matter whether the doxygen package
ships jquery inside a binary or in a separate file. Both are contained
in the package and both are compiled (albeit differently). What you
describe is not a worthwhile goal to me.

If you intend to work on aspect 1. (embedding of jquery sources in the
doxygen source package) then surely the first step would be *packaging*
the missing libraries. Can you point me to the work you have done in
that area?

I also do not see any aspects of you addressing embedding 2. or 3.
(minified jquery in doxygen source package). At no point do you add code
that touches the build system.

Your initial patch does not address any of your claimed goals!

As I have pointed out in my previous mail, I do not see moving the
resources from one place to another as a worthwhile goal.

I have already investigated this option. When I asked Doxygen upstream
about API stability of the bundled jquery libraries Dimitri explicitly
denied any kind of forwards- or backwards-compatibility. That means that
any documentation package depending on a doxygen-data package will need
a versioned dependency. When a new version of doxygen gets uploaded, all
reverse build-dependencies therefore need to be rebuilt. Unfortunately
for us, most of them are Architecture:all and we currently only do
Architecture:any binNMUs. While I agree that this would ultimately be
the best outcome, it is not currently possible. If you intend to further
this goal, please work on Architecture:all autobuilding.

Unless you add substantial information to this bug report, I am inclined
to close it. As is, this bug report is in no way actionable.

Helmut

À : "Helmut Grohne" <helmut@subdivi.de>
Cc :


Le 23 janv. 2014 20:10, "Helmut Grohne" <helmut@subdivi.de> a écrit :
2. 3

For me it is a worthwhile goal reduce archive size.
package.

No because with a few script line we could render jquery backward
compatible. We do not care about doxygen.

We load recent jquery and we add some compatibility layer see
https://github.com/jquery/jquery-migrate/blob/master/README.md

Bastien

Hi Bastien,

When moving files within a package there is no reduction in size. That
is precisely why the goal did not seem worthwhile to me. In any case it
is not substantial. We are talking about a few kb if anything. Space is
not a reasonable argument here, sorry.

On the other hand the Debian policy discourages the use of embedded code
copies. The main reason here is that the work to fix a bug in the code
is amplified by the number of embedded copies.

While it may be possible to make jquery backwards compatible, that's not
the goal here. The goal for Doxygen would be to make the embedded file
called jquery.js backwards compatible. These are two very different
goals, because (I repeat) what is called jquery.js is not jquery, but
happens to also contain jquery.

None of your past mails show that you have understood the scope of the
problem. Please take a bit more time and think things through before
replying. I am not opposed to solving the embedding issue, but I do not
yet see, how you intend to solve it.

Helmut

Given that this report has not received sufficient information to
warrant the patch tag I am turning the issue into what I believe is at
its core: the embedding of jquery. It is already well documented at
/usr/share/doc/doxygen/README.jquery. The issue obviously results from
upstream decisions and I am not the one fixing it in the current
ecosystem. That means the tag wontfix will stay until at least one of
the following conditions is met:

 * We can do Arch:all binNMUs.
 * All relevant jquery auxiliary libraries are packaged and there is
   commitment to packaging the future libraries Doxygen upstream will
   introduce.
 * There is a patch, that does not break legitimate use cases.

Given that I am not doing the work, there are no tracker bugs for the
former two issues. If they are created, I'd appreciate relevant block
commands to the bts.

Still hoping that I am wrong and things are easier than this. ;-)

Helmut

Would it be feasible to make Debian's Doxygen (or even upstream Doxygen)
install its combined JavaScript library as doxygen.js or
doxygen-${DEB_VERSION_UPSTREAM}.js or something, instead of naming it
jquery.js?

That wouldn't solve the embedding, but it would at least stop maintainers
(and Lintian) from getting confused, thinking that it's just jQuery,
and applying a wrong "fix". If the name included the Doxygen version, then
it would also facilitate tracking which packages contain (parts of) which
Doxygen versions.

(I ask because I've run into this more than once while sponsoring/NMUing
for the libstdc++ transition.)

Regards,
    S

Control: clone -1 -2
Control: tags -2 =
Control: retitle -2 rename inserted jquery.js to something that includes the Doxygen version

Thank you very much for this idea. I like it to the point that even
carrying it as a Debian-specific patch would outweigh its maintenance
cost as I have experienced similar pain with explaining what "jquery.js"
is. In particular, this would immediately unbreak all wrongly "fixed"
packages (after a rebuild).

A slight bit of care needs to be taken as Doxygen can be run
incrementally and someone might want to update an old tree with a
Doxygen version after this change.

If not implemented in Doxygen itself, it could also live in dh_doxygen
as a fixup step. That should amount to a move of a file together with
replacing the reference (or adding a symlink jquery.js ->
doxygen-$VER.js even).

Your proposed change would also obsolete #736360.

That said, I of course do prefer pushing this upstream. Dimitri van
Heesch (upstream) already acknowledged that the jquery blob is not
compatible across Doxygen versions, so I guess that he would be
receptive to this idea and he has taken patches from the reproducible
builds folks recently.

I don't see myself working on this soon as the new upstream release
switches from tmake to cmake which is already a significant amount of
work (and also depends on #794396).

Helmut

Hi,

Can someone explain the use of JQuery like I'm five to me? I'm asking because JQuery
requires "uglifyjs" which has a runtime dependency on NodeJS which heavily restricts
buildability of the reverse dependencies due to Google's unwillingness to provide a
generic, slow implementation of their V8 JavaScript engine. This limits the whole
NodeJS stack to architectures with big companies behind as others don't have the funds
to support a V8 port.

From what I understand, all that NodeJS does here is take some JavaScript code and
transpile it into other JavaScript code. I have never understood the purpose of this
but Firefox suffers from the same problem [1] which makes the browser package which
itself is very portable exclusive to release architectures.

On the other hand, the JavaScript files can also be "cross-transpiled" from architectures
that have NodeJS support to architectures which don't. Oracle does this in Solaris allowing
them to build and ship Firefox for Solaris SPARC [2].

Wouldn't it be possible to do that here as well? Can't we just transpile the JavaScript
on amd64 and stuff the result into the doxygen-common package?

FWIW, I was able to build the doxygen package on sparc64 without the uglifyjs build
dependency and after removing the call to jquery in debian/rules.

Adrian

Hi Adrian,

[recording parts of our IRC conversation in mail]

I think what you really want here is an explanation of why uglifyjs is
needed rather than JQuery. The /usr/bin/doxygen binary contains a
minified JQuery. We use uglifyjs to create this version from Doxygen's
vendor copy of JQuery (which actually is not JQuery but a collection of
JQuery plus some other libraries and some bits added by Doxygen). The
purpose here was building from source as much as possible.

Confirmed.

Yes. If /usr/bin/doxygen were able to load the minified jquery.js from
an external file rather than stuffing it into a const char* variable, we
could do that.

Yes, I think that would be feasible (assuming the aforementioned
change). That way, uglifyjs could plausibly be moved to B-D-I.

Another alternative could be adding a pkg.doxygen.prebuiltjs build
profile that would drop the uglifyjs dependency in favor of using the
minified JQuery in the source tarball without rebuilding it.

That said, I no longer am a Doxygen maintainer and have no more say in
what is or is not acceptable.

Helmut