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
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 developme
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,
Ach
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.
Achim Gratz writes:
> http://orgmode.org/worg/dev/org-build-system.html
>
> I'll add that link to `make help´.
Good idea, thanks!
--
Bastien
Achim Gratz 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 targets.
The
Achim Gratz 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 you find it fr
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. Un
Achim Gratz 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 developers)
>>
>
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 a
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 cur
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
Achim Gratz writes:
> Bastien 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.
Bastien 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 stan
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 y
Achim Gratz 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.
>
> These wa
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 pr
Bastien 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 an
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 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 a
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 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 things as well,
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 by
>> 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.
Wait, I must have missed something. Some warnings are not showing?
I do something like make >output 2>&1 ; grep -i 'error\|warning'
output. Good code has no warnings, I thought?
Samuel
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
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
Hi Achim,
Achim Gratz 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 the default "m
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 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
At long last the promised documentation for the build system starts to
materialize on Worg:
http://orgmode.org/worg/dev/org-build-system.html
It undoubtedly needs improvement, so please let me know where and/or add
to it yourself. Thank you.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neu
30 matches
Mail list logo
