Bastien writes:
I'll stick to this: it is good to document all existing targets.
The question is whether a target should be displayed by `make helpall'
rather than just ̀make help'.
As long as `make helpall´ was all the documentation that meant it had to
look like it does.
Regards,
Achim.
Bastien writes:
[...]
I hope you'll understand the choices above.
You should know the answer from the previous discussion, but I've
clearly failed to reach you. Given your obvious desire to take over
direct control of the further development of the build system, I won't
do any further
Hi Achim,
it is not a matter of taking over the build system, it is a matter
of making it simple for the users and useful for the developers.
At least two of the core developers here want `make compile-single'
and don't want to edit local.mk to do so.
The reverts I did were just for this to be
Eric Schulte writes:
I second the idea that a top level 'make elint' would be very useful for
developers (see the attached patch).
I'll see to implement that when and if I get elint to process the Org
sources without throwing bogus warnings and errors because it runs into
some depth limit.
Achim Gratz strom...@nexgo.de writes:
You found the time and energy to edit Makefile and targets.mk, so
presumably you might be able to edit local.mk as well as I suggested
numerous times. So please go ahead and actually do it and then after
you've used elint for a while tell me how useful
Achim Gratz strom...@nexgo.de writes:
cleandirs, cleancontrib, cleantesting, cleanutils, cleanelc
Internal use and compatibility, I could remove the documentation if
Bastien changes his mind about all the target needing documentation.
I'll stick to this: it is good to document all existing
Achim Gratz strom...@nexgo.de writes:
http://orgmode.org/worg/dev/org-build-system.html
I'll add that link to `make help´.
Good idea, thanks!
--
Bastien
Hi Achim,
I reverted the commits introducing the _COMPILE_ variable and the elint
targets in the makefile.
I'm with Eric on thinking that even the casual developer should not have
to tweak his local.mk to run the equivalent of `make compile-single', as
it is directly useful to get some warnings.
Bastien writes:
One thing I need to understand: what are the warnings that you have
when compiling within a single process and you don't when compiling
with one process per file?
Emacs Lisp as a dynamic language has no concept of a well-formed
program that can be verified by just looking at
Please give me an example of a warning that is shown while compiling
within a single Emacs process and not shown while compiling files with
one Emacs process per file.
--
Bastien
Bastien bzg at gnu.org writes:
Please give me an example of a warning that is shown while compiling
within a single Emacs process and not shown while compiling files with
one Emacs process per file.
I don't know if something like that currently exists, if you want to check set
_COMPILE_=slint2
I tried _COMPILE_ = single
and I tried
~$ emacs -batch -Q --eval (byte-compile-file
\~/install/git/org-mode/lisp/ob.el\)
I get warnings in the second case, not in the first case.
Is there anything that _COMPILE_=single loads/expands on top of a
bare Emacs when compiling using one Emacs
Achim Gratz strom...@nexgo.de writes:
Eric Schulte writes:
But we certainly shouldn't (and currently aren't?) inhibit the display
of any warnings when the default make is run. I was surprised to run
make compile-source and see additional warnings which weren't shown
during regular make.
Let's summarize.
It is no a matter of exposing the user to the warnings or not.
It is a matter of exposing the user to the warnings that might be
useful to him -- i.e. the ones he might want to report to the list
just to let the developers know, or in the context of a bug hunt.
The warnings
Bastien bzg at gnu.org writes:
~$ emacs -batch -Q --eval (byte-compile-file
\~/install/git/org-mode/lisp/ob.el\)
I get warnings in the second case, not in the first case.
You should, because the command line you use does not set up the load-path
correctly. The requires will now use the
Achim Gratz strom...@nexgo.de writes:
Bastien bzg at gnu.org writes:
~$ emacs -batch -Q --eval (byte-compile-file
\~/install/git/org-mode/lisp/ob.el\)
I get warnings in the second case, not in the first case.
You should, because the command line you use does not set up the load-path
Bastien writes:
Do you get them with make
~$ make _COMPILE_=single
Not now, but I've seen them before. I think this is one of those cases
where an indirect require provides a dependency.
How do you set up the load-path
The current directory (which is lisp) is prepended to the load-path,
Bastien writes:
However, I would suggest these changes to the current default.mk:
These changes do not belong into default.mk — default.mk is the fallback
for when no changes to local.mk have been made.
- Have a target `make single' (useful for developers)
- `make elint' would run the
Eric Schulte writes:
I don't find the strings single compile, compile-source or elint
anywhere in the Org documentation. Perhaps there is different
documentation for the Makefile?
Yes, as mentioned several times in this thread:
http://orgmode.org/worg/dev/org-build-system.html
I'll add that
Achim Gratz strom...@nexgo.de writes:
Bastien writes:
However, I would suggest these changes to the current default.mk:
These changes do not belong into default.mk — default.mk is the fallback
for when no changes to local.mk have been made.
- Have a target `make single' (useful for
Bastien writes:
Please make the default make procedure display all warnings that the
user would see by compiling Emacs itself.
That isn't even possible, you'd need to use Emacs' build system (which,
btw gives inconsistent results for repeated compiles).
I know we disagree about this: you
Wait, I must have missed something. Some warnings are not showing?
I do something like make output 21 ; grep -i 'error\|warning'
output. Good code has no warnings, I thought?
Samuel
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
I know we disagree about this: you think that compiler warnings are for
the developers, not for the users. I think the default make should
send as much warnings as Emacs sends with its own default make.
You continue to misunderstand what I was saying or at least trying to
say. The primary
Eric Schulte writes:
But we certainly shouldn't (and currently aren't?) inhibit the display
of any warnings when the default make is run. I was surprised to run
make compile-source and see additional warnings which weren't shown
during regular make.
These warnings aren't reliable — the byte
Hi Achim,
Achim Gratz strom...@nexgo.de writes:
You continue to misunderstand what I was saying or at least trying to
say. The primary function of Org's build system is to, well, build Org
with the minimum fuzz. That's what it was designed to do and that is
what it does — it can do other
By the way, I just tried to compile with
_COMPILE_ = source
in default.mk (instead of _COMPILE_ = dirall, which I commented) and it
seems to compile twice (as with single+dirall) and it does not remove
the *elc files, as advertized.
Anything I miss here?
Thanks,
--
Bastien
Hi Achim,
Achim Gratz strom...@nexgo.de writes:
I've just pushed a change to the Makefile to more easily allow
customization of compilation methods. See
http://orgmode.org/worg/dev/org-build-system.html#sec-3-2-1
for what is available.
Thanks for taking care of this page.
Please make
I've just pushed a change to the Makefile to more easily allow
customization of compilation methods. See
http://orgmode.org/worg/dev/org-build-system.html#sec-3-2-1
for what is available.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptations
Achim Gratz strom...@nexgo.de writes:
At long last the promised documentation for the build system starts to
materialize on Worg:
http://orgmode.org/worg/dev/org-build-system.html
Great. Thanks for writing this up!
--
Bastien
29 matches
Mail list logo
