Why two blank lines, not just one as for the other scripts?
Slip of the editor. Will fix. Thanks for the sharp eyes. -k
END
> }
>
Why two blank lines, not just one as for the other scripts?
Bruno
On 21 Jan 2024 14:42, Karl Berry wrote:
> I changed the pretest version to 1.16.90. Closing.
thx bud. i appreciates you.
-mike
signature.asc
Description: PGP signature
I changed the pretest version to 1.16.90. Closing.
"Zack Weinberg" writes:
> On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
>> On 13 Jan 2024 15:58, Karl Berry wrote:
>>> Another alternative: when this came up 30-odd years ago, rms changed the
>>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>>> that would at
On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
> On 13 Jan 2024 15:58, Karl Berry wrote:
>> Another alternative: when this came up 30-odd years ago, rms changed the
>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>> that would at least have the benefit of following
On 13 Jan 2024 15:58, Karl Berry wrote:
> Another alternative: when this came up 30-odd years ago, rms changed the
> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
> that would at least have the benefit of following a recommendation, and
> as a side effect, would also fix
there is nothing requiring or restricting the current version behavior
other than "it's always been this way".
True.
but that doesn't mean it's better.
No way to know what release or test scripts might be relying on the
current convention. Changing for the sake of chan
On 06 Jan 2024 15:37, Karl Berry wrote:
> Automake and other packages have used letters for pretests for decades,
true ...
> and it's not plausible to change now.
eh ? there is nothing requiring or restricting the current version behavior
other than "it's always been this way". but that
Carl - sorry, you'll need to adjust your script. Automake and other
packages have used letters for pretests for decades, and it's not
plausible to change now.
Also, I have the impression that other packages use random git hexids in
their pretest releases, which aren't numeric either. -k
Building a package (happens to be "jami") , which runs a script it its
build process that checks for automake
expr: non-integer argument
automake (GNU automake) 1.16j
Fatal error: automake 1.7 or higher is required. Please set $AUTOMAKE
to point to a
Hello,
Nick Bowler <nbow...@draconx.ca> writes:
> On 2017-10-14, Joël Krähemann <jkraehem...@gmail.com> wrote:
>> I need some authoritative answer about copyright notices to be used
>> for scripts and templates. The files generated by autoscan, autoconf,
>>
On 2017-10-14, Joël Krähemann <jkraehem...@gmail.com> wrote:
> I need some authoritative answer about copyright notices to be used
> for scripts and templates. The files generated by autoscan, autoconf,
> automake or alike.
>
> I need this information in order to proc
Hi,
I need some authoritative answer about copyright notices to be used
for scripts and templates. The files generated by autoscan, autoconf,
automake or alike.
I need this information in order to proceed with a submission on
savannah.gnu.org,
https://savannah.gnu.org/task/index.php?14667
On 11/02/2016 08:06 PM, Raphaël Halimi wrote:
Hi Peter,
Thanks for your answer.
Just to make sure I understand:
CLEANFILES += data/.dirstamp
data/.dirstamp:
@$(MKDIR_P) data
@: > $@
This creates a directory "data", and then a file ".dirstamp" in this
directory by redirecting
Hi Peter,
Thanks for your answer.
Just to make sure I understand:
> CLEANFILES += data/.dirstamp
>
> data/.dirstamp:
> @$(MKDIR_P) data
> @: > $@
This creates a directory "data", and then a file ".dirstamp" in this
directory by redirecting the (empty) result of the "true" command to
yout as the source
tree; its subdirectories are created automatically by the build system."
Unfortunately, it doesn't seem to be true for the SCRIPTS primary (I
assume it's true and works as expected for compiled binaries and
libraries, I can't know, I'm new to autotools and I'm a sysadmin,
bdirectories are created automatically by the build system."
>
>> Unfortunately, it doesn't seem to be true for the SCRIPTS primary (I
>> assume it's true and works as expected for compiled binaries and
>> libraries, I can't know, I'm new to autotools and I'm a sysad
fortunately, it doesn't seem to be true for the SCRIPTS primary (I
> assume it's true and works as expected for compiled binaries and
> libraries, I can't know, I'm new to autotools and I'm a sysadmin, I
> develop only scripts, nothing compiled).
I've run into this problem before, and j
umentation:
"The build tree usually has the same subdirectory layout as the source
tree; its subdirectories are created automatically by the build system."
Unfortunately, it doesn't seem to be true for the SCRIPTS primary (I
assume it's true and works as expected for compiled binaries and
librarie
with (simplified version), simply adding new Lua files
to nobase_dist_lua_DATA will automagically compile them using luac and your
preferred luac flags.
nobase_dist_lua_DATA = \
scripts/example_one.luac \
scripts/example_two.luac
LUA_CC = luac
LUA_CC_FLAGS = -s
LUA_OBJECTS
Hello, I have a C project which uses Autoconf and uses Lua for scripting.
I want Automake to be able to compile the Lua scripts to bytecode with luac.
It is possible to compile a Lua script to bytecode like this:
luac -o myscript.luac myscript.lua
How do I instruct Automake to use luac
Hi
In one of our projects we have several python scripts that we need to
ensure that the python interpreter is set to the one found by
configure. At the moment we are doing this by having the interpreter
set to @PYTHONPROG@ and then using the following rule:
python_config.sed:
@-rm -f
On 07/31/2013 03:23 PM, Adam Mercer wrote:
Hi
In one of our projects we have several python scripts that we need to
ensure that the python interpreter is set to the one found by
configure. At the moment we are doing this by having the interpreter
set to @PYTHONPROG@ and then using
(cc-ing automake mailing list)
Hi all, do you think that there would be possible to cover upstream
creation of system wide config.{sub,guess} scripts? Possible patch
is at the bottom of this mail.
Nothing would change from the target-project point of view - just that if
the user's distribution
+++ Pavel Raiskup [2013-04-05 11:15 +0200]:
(cc-ing automake mailing list)
Hi all, do you think that there would be possible to cover upstream
creation of system wide config.{sub,guess} scripts? Possible patch
is at the bottom of this mail.
This was recenly discussed (oct 2012
and scripts. ##
+## ##
+
+EXTRA_DIST += \
+ maint/am-ft \
+ maint/am-xft \
+ maint/rename-tests
diff --git a/maint/am-ft b/maint/am-ft
new file mode 100755
index 000..d8a2722
--- /dev/null
+++ b/maint/am-ft
@@ -0,0 +1,109 @@
+#!/usr/bin/env bash
+# Remote
/scripts/install.sh), which was
# later released in X11R6 (xc/config/util/install.sh) with the
# following copyright and license.
@@ -519,9 +517,4 @@ do
done
# Local variables:
-# eval: (add-hook 'write-file-hooks 'time-stamp)
-# time-stamp-start: scriptversion=
-# time-stamp-format: %:y-%02m
still revert it at
a later date, if the outcry against it is loud enough *and* if someone
is ready to write a proper git merge driver.
Alas, all the affected scripts also have a '--version' option, which use
the '$scriptversion' variable. So I fear my so-desired removal of this
variable
Basically an adjusted-and-improved cherry-pick from Automake-NG
commit v1.12.1-343-gff30f83.
* t/specflg.sh, t/specflg2.sh, t/specflg3.sh: Merged into ...
* t/per-target-flags.sh: ... this test.
* t/fo.sh: Remove, its weak grepping checks well superseded by
the semantic checks in 't/fort4.sh'.
*
This will allow the developers to run a tests case by hand out of
a newly extracted tarball simply doing:
$ ./configure make
$ ./runtest t/the-test-case.sh
while before this change one has to resort to:
$ ./configure make make check TESTS=
$ ./runtest t/the-test-case.sh
or,
Le 21 juil. 2012 à 10:50, Stefano Lattarini a écrit :
See long-standing automake bug#7868.
* t/parallel-tests-many.sh: Simplify and enhance. Among the other things,
I would s/the //.
this test now tries running ~ 30 thousands tests. Currently fails on
I would also 30,000, I don't like
Le 22 juil. 2012 à 09:58, Stefano Lattarini a écrit :
I personally use it extensively in my test suites, as I find this
much more legible:
! list_logs | grep .
Ah, but this doesn't do what you expect:
$ bash -c '! echo x | grep .'; echo st = $?
x
st = 0
$ bash -c '! echo | grep
: $count
-*
-END
-fi
-
-$MAKE check TESTS=$deepdir/$tname-1.test \
- test -f $deepdir/$tname-1.log \
- || framework_failure_ \make check\ with one single tests
-
-rm -f $deepdir/* || exit 99
+# Number of test scripts will be 3
tags 11898 + patch
close 11898
thanks
On 07/11/2012 11:30 AM, Stefano Lattarini wrote:
[PATCH] tests: verify the shell test scripts are syntactically valid
This measure of extra safety is mostly motivated by the fact that some
shells (at least some versions of Bash in the 3.x release series
with exit status
0 upon encountering a syntax error, if an exit trap is sett (as it is in
our test scripts).
* Makefile.am (check-tests-syntax): New, check that the shell test
scripts listed in $(TESTS) are syntactically correct.
(.PHONY, check-local): Depend on it.
* t/self-check-exit.tap : Remove
\
sc_m4_am_plain_egrep_fgrep \
sc_tests_no_configure_in \
sc_tests_PATH_SEPARATOR \
@@ -446,6 +447,19 @@ sc_tests_ls_t:
exit 1; \
fi
+## Test scripts must be executable.
+sc_tests_executable:
+ @st=0; \
+ for f in $(xtests); do \
+ case $$f in \
+ t
point. When you upgrade your build system to
a new Automake version, you should run automake with the --force option,
to ensure that the automake-installed scripts are updated even if they
are already present in the build tree. But if you fail to do so, you
don't get any warning, which
to a new automake version.
It isn't obvious that just because some other tool was updated that I
now have to rerun with a --force option.
to ensure that the automake-installed scripts are updated even if they
are already present in the build tree. But if you fail to do so, you
don't get any
is a developer meant to notice that he's doing something
wrong if 'automake -Wall' does not tell him?
This is actually a good point. When you upgrade your build system to
a new Automake version, you should run automake with the --force option,
to ensure that the automake-installed scripts are updated
Eric Blake wrote:
Any idea for a simple solution to this problem?
Aren't there timestamps in the auxiliary scripts for a reason? If a
script is updated as part of a new automake release, can't automake
insert some sanity checks to see if the currently-installed scripts have
too old
On 06/26/2012 12:04 PM, Bruno Haible wrote:
Eric Blake wrote:
Any idea for a simple solution to this problem?
Aren't there timestamps in the auxiliary scripts for a reason? If a
script is updated as part of a new automake release, can't automake
insert some sanity checks to see
On 06/26/2012 10:15 AM, Stefano Lattarini wrote:
What about this: since the great majority of the packages out there do
not seem to override nor patch the Automake-provided auxiliary scripts,
we could just make automake always reinstall such scripts by default;
and allow the users to mark
Hi Eric.
On 06/26/2012 06:29 PM, Eric Blake wrote:
On 06/26/2012 10:15 AM, Stefano Lattarini wrote:
What about this: since the great majority of the packages out there do
not seem to override nor patch the Automake-provided auxiliary scripts,
we could just make automake always reinstall
These three scripts are too closely tied to automake internals to
be independently useful. In fact, automake would rather that
people did not mix the latest version of these scripts with older
versions of automake, as there is no effort being put into
maintaining backwards-compatibility when
[adding autoconf]
On 06/26/2012 12:26 PM, Bruno Haible wrote:
Eric Blake wrote:
* build-aux/elisp-comp: Delete.
What about modules/elisp-comp?
That module has only had one edit: it's introduction in 2006:
https://lists.gnu.org/archive/html/bug-gnulib/2006-08/msg00248.html
with a claim that
On 06/26/2012 09:12 PM, Eric Blake wrote:
[SNIP]
And not mentioned in my proposed commit message, but I specifically kept
mdate-sh as one of the mirrored files, even though Stefano originally
suggested that it might be automake-centric; that particular script is
small enough to be useful in
On 06/21/2012 09:38 PM, Stefano Lattarini wrote:
On 06/14/2012 09:55 PM, Stefano Lattarini wrote:
This is as far as I got in my line-by-line review in the time I have
today; if you want to wait for another few days, I can resume my review
in time for your initial push. Or you can go ahead
On 06/14/2012 09:55 PM, Stefano Lattarini wrote:
This is as far as I got in my line-by-line review in the time I have
today; if you want to wait for another few days, I can resume my review
in time for your initial push. Or you can go ahead and push, and I can
report any further issues for
On 06/14/2012 10:17 AM, Stefano Lattarini wrote:
Since commit 'v1.12-36-g2d68fd9' of 2012-05-07, configure: search a
sturdy POSIX shell to be used in the testsuite, the shell running
our test script is assured to be a POSIX-conforming shell, so we can
use the more modern and flexible idioms
-functions.sh'
and a good part of 'defs' in an external testsuite library for shell scripts
(maybe Gnulib's 'tests/init.sh'? that would be great), in which case it might
make sense to re-introduce the 'incr_' function.
+++ b/t/autodist.sh
@@ -39,7 +39,7 @@ list=`$AUTOMAKE --help \
| sed -n
On 05/06/2012 09:07 PM, Bruno Haible wrote:
Hi,
Hi Bruno, sorry for the delay (I had somehow missed this mail of yours).
The Automake manual, node Scripts, says:
Scripts can be installed in `bindir', `sbindir', `libexecdir',
`pkglibexecdir', or `pkgdatadir'.
Also http
On 05/01/2012 10:04 AM, Stefano Lattarini wrote:
This is just a preparatory refactoring for future changes.
Sorry for my delay in reviewing; I'm now looking at this series.
* configure.ac (AM_TEST_RUNNER_SHELL): New variable, defined
to $SHEL', and AC_SUBST'd.
s/SHEL/SHELL/
@@ -105,16
Hi Eric, thank you very much for the review.
On 05/07/2012 04:34 PM, Eric Blake wrote:
On 05/01/2012 10:04 AM, Stefano Lattarini wrote:
This is just a preparatory refactoring for future changes.
Sorry for my delay in reviewing; I'm now looking at this series.
* configure.ac
Hi,
The Automake manual, node Scripts, says:
Scripts can be installed in `bindir', `sbindir', `libexecdir',
`pkglibexecdir', or `pkgdatadir'.
Also http://lists.gnu.org/archive/html/automake/2012-01/msg4.html
confirms this.
But why is this set of install locations limited? Why
Hi Nick, and thanks for the patch.
On 05/04/2012 04:14 PM, Nick Alcock wrote:
We'll have later is a rare example of English in the Automake
manual clearly not written by a native English-speaker:
Yes, that would be me :-)
while comprehensible, it could be better formulated.
Signed-off-by:
We'll have later is a rare example of English in the Automake
manual clearly not written by a native English-speaker: while
comprehensible, it could be better formulated.
Signed-off-by: Nick Alcock nick.alc...@oracle.com
---
doc/automake.texi |5 ++---
1 file changed, 2 insertions(+), 3
* tests/instdir-cond.test: Add executable bit.
* tests/instdir-cond2.test: Likewise.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 = 100755 tests/instdir-cond.test
mode change 100644 = 100755
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
This is fine and good for scripts which are formally installed, but
while they (originals) are in the source tree, there are definite
benefits for scripts to have a useful extension. This is particularly
true if people build in the source
that people could chmod +x the configure script before running it, but
I've never had to do that.
You can just do sh configure... (and I think autoconf/automake are
careful to never rely on the execute bits of helper scripts being
set).
Anyway, it's not really the same issue. configure is either part
every package with a configure script rely on this? I suppose
that people could chmod +x the configure script before running it, but
I've never had to do that.
You can just do sh configure... (and I think autoconf/automake are
careful to never rely on the execute bits of helper scripts being
NightStrike nightstr...@gmail.com writes:
The shell-scripts in question, however, are source files, and so come
directly via whatever mechanism you use to get source files -- tar,
cp, random-vcs-xyz, In many cases such mechanisms can preserve
execute bits, but ... it doesn't feel quite
On 2012-03-22 22:29 +0900, Miles Bader wrote:
NightStrike nightstr...@gmail.com writes:
You are now saying that you want the source distribution to contain
files with execute permissions, but you still haven't explained how
you were doing that in your original example.
No I'm not.
I'm
2012年3月21日13:13 NightStrike nightstr...@gmail.com:
Here's a better question. How do you insure that your current file is
executable? Do it the same way.
Er cp $ $@ chmod +x $@ ... :]
[Relying on source-code execute bits always being correctly maintained
is one of those things that ...
Miles Bader mi...@gnu.org writes:
[Relying on source-code execute bits always being correctly maintained
is one of those things that ... well... doesn't really feel very robust.
I dunno, maybe it's just me...]
Doesn't every package with a configure script rely on this? I suppose
that people
On Wed, 21 Mar 2012, Russ Allbery wrote:
Miles Bader mi...@gnu.org writes:
[Relying on source-code execute bits always being correctly maintained
is one of those things that ... well... doesn't really feel very robust.
I dunno, maybe it's just me...]
Doesn't every package with a configure
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
On Wed, 21 Mar 2012, Russ Allbery wrote:
Miles Bader mi...@gnu.org writes:
[Relying on source-code execute bits always being correctly maintained
is one of those things that ... well... doesn't really feel very robust.
I dunno, maybe it's
On Tue, Mar 20, 2012 at 9:06 PM, Miles Bader mi...@gnu.org wrote:
2012年3月21日13:13 NightStrike nightstr...@gmail.com:
Here's a better question. How do you insure that your current file is
executable? Do it the same way.
Er cp $ $@ chmod +x $@ ... :]
[Relying on source-code execute
-policy/ch-files.html#s-scripts
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
signature.asc
Description: This is a digitally signed message
your program into debian:
http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
This is fine and good for scripts which are formally installed, but
while they (originals) are in the source tree, there are definite
benefits for scripts to have a useful extension. This is particularly
On Tue, Mar 20, 2012 at 15:47, Nick Bowler nbow...@elliptictech.com wrote:
On 2012-03-20 07:00 +0900, Miles Bader wrote:
Is there a recommended way for dealing with binaries that are simple
shell scripts in automake? I currently use something like the
following:
bin_PROGRAMS = myprog
On Tue, Mar 20, 2012 at 03:18, Miles Bader mi...@gnu.org wrote:
Harlan Stenn st...@ntp.org writes:
What's the problem with bin_SCRIPTS?
Hmm, I didn't know about it, but ... reading the documentation,
bin_SCRIPTS doesn't actually seem to do much of anything -- you
still have to add your own
On 2012-03-20 16:01 +0200, Andrew W. Nosenko wrote:
On Tue, Mar 20, 2012 at 15:47, Nick Bowler nbow...@elliptictech.com wrote:
[...]
SUFFIXES = .sh
.sh:
$(shbin_verbose) cp $ $@.tmp
$(AM_V_at) chmod +x $@.tmp
$(AM_V_at) mv -f $@.tmp $@
Why do not use
On Mon, Mar 19, 2012 at 3:18 PM, Miles Bader mi...@gnu.org wrote:
Harlan Stenn st...@ntp.org writes:
What's the problem with bin_SCRIPTS?
Hmm, I didn't know about it, but ... reading the documentation,
bin_SCRIPTS doesn't actually seem to do much of anything -- you
still have to add your own
2012年3月21日8:33 NightStrike nightstr...@gmail.com:
bin_SCRIPTS doesn't actually seem to do much of anything -- you
still have to add your own rules to handle all the actual work, need
to fiddle with EXTRA_DIST and CLEANFILES, etc. Indeed, doing what I
You can avoid hacking EXTRA_DIST if you
On Tue, Mar 20, 2012 at 1:55 PM, Miles Bader mi...@gnu.org wrote:
2012年3月21日8:33 NightStrike nightstr...@gmail.com:
bin_SCRIPTS doesn't actually seem to do much of anything -- you
still have to add your own rules to handle all the actual work, need
to fiddle with EXTRA_DIST and CLEANFILES,
On Tue, 20 Mar 2012, NightStrike wrote:
Yes. There's an earlier email in this thread from somebody
illustrating that you don't need to morph from source to script if the
file doesn't actually get changed.
How will Microsoft Windows File Manager and KDE's Dolphin know how to
open the proper
Yes, and you also don't need to worry about DIST if you are using a .in
file and letting config.status (via configure) do the substituting.
H
2012年3月21日9:32 NightStrike nightstr...@gmail.com:
dist_bin_SCRIPTS = aaa
That's going to distribute aaa, though, right, not the actual
source e.g. aaa.sh?
Yes. There's an earlier email in this thread from somebody
illustrating that you don't need to morph from source to script if the
file
On Tue, Mar 20, 2012 at 3:16 PM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
On Tue, 20 Mar 2012, NightStrike wrote:
Yes. There's an earlier email in this thread from somebody
illustrating that you don't need to morph from source to script if the
file doesn't actually get changed.
are there in your
sources. Your version control software should be able to preserve
permissions, too. For instance, for svn, you can set the svn:execute
property. When installing, $INSTALL will automatically set the
permissions accordingly for the SCRIPTS primary.
Here's a better question. How do you
Is there a recommended way for dealing with binaries that are simple
shell scripts in automake? I currently use something like the
following:
bin_PROGRAMS = myprog
myprog_SOURCES = myprog.sh
myprog: myprog.sh
%: %.sh
$(shbin_verbose)cp $ $@; chmod +x $@
shbin_verbose
Miles Bader mi...@gnu.org writes:
Is there a recommended way for dealing with binaries that are simple
shell scripts in automake? I currently use something like the
following:
bin_PROGRAMS = myprog
myprog_SOURCES = myprog.sh
myprog: myprog.sh
%: %.sh
What's the problem with bin_SCRIPTS?
H
Harlan Stenn st...@ntp.org writes:
What's the problem with bin_SCRIPTS?
Ack, sorry, that's what I meant in my reply.
Note that the Automake documentation also defines how to handle variable
substitution if necessary for scripts, although it doesn't have the magic
to handle non-verbose builds
Harlan Stenn st...@ntp.org writes:
What's the problem with bin_SCRIPTS?
Hmm, I didn't know about it, but ... reading the documentation,
bin_SCRIPTS doesn't actually seem to do much of anything -- you
still have to add your own rules to handle all the actual work, need
to fiddle with EXTRA_DIST
.
There are reasons for using it for scripts instead of using _PROGRAMS.
H
it and see for yourself.
There are reasons for using it for scripts instead of using _PROGRAMS.
H
... and try using as little as possible - I think you will be pleasantly
surprised.
H
our scripts (in maint and master
as well).
It wouldn't have been a lie if changes happened in the right place,
at least not for the vast majority of changes, i.e. the backwards
compatible ones. Also remember that the consensus seemed to be that
scriptversion is useful last time this came up
-1.11. I.e. for the master case:
git checkout master; git merge --strategy=ours maint
and similar for branch-1.11. And then, finally, get rid of the obnoxious
msvc branch...
After that, we should be able to go back to the old simple rule of only
updating the scripts on maint.
I tried
Stefano Lattarini skrev 2012-03-05 21:00:
On 03/05/2012 02:25 PM, Peter Rosin wrote:
Hi!
I noticed that some expect the compiler to accept a space between
the option letter and the option argument. Looking at POSIX, this
seems like an acceptable expectation, if not even preferred. So,
On 03/06/2012 09:44 AM, Peter Rosin wrote:
I made the changes and pushed, but it feels a bit hard to read -l${sp}foo
compared to -lfoo, so I'm not too happy about it. Oh well...
Thanks.
Regards,
Stefano
the rule saying
newer is better.
But that's a lie anyway when we use multiple branches, as the present
situation shows once again. OK, enough is enough. Tomorrow I'll just
nuke all the 'scriptversion' lines from our scripts (in maint and master
as well).
It wouldn't have been a lie if changes
compile/depcomp/ar-lib on maint destroys the rule saying
newer is better.
But that's a lie anyway when we use multiple branches, as the present
situation shows once again. OK, enough is enough. Tomorrow I'll just
nuke all the 'scriptversion' lines from our scripts (in maint and master
as well
POSIX mandates that the compiler accepts a space between the -I,
-l and -L options and their respective arguments.
* lib/compile (func_cl_dashl): New function with factored out code
for implementing the -l option for the cl wrapper.
(func_cl_dashL): New function with factored out code
On 03/05/2012 02:25 PM, Peter Rosin wrote:
Hi!
I noticed that some expect the compiler to accept a space between
the option letter and the option argument. Looking at POSIX, this
seems like an acceptable expectation, if not even preferred. So,
here's an update for the compile script when
On 03/01/2012 08:36 PM, Peter Rosin wrote:
* lib/ar-lib: Implement the q (quick) action as a synonym
for r (replace). Ignore s (symbol index) and S (no symbol
index) when used as modifiers and s when used as a command,
there is simply no way for Microsoft lib to not update the
symbol table
Stefano Lattarini skrev 2012-03-02 10:32:
On 03/01/2012 08:36 PM, Peter Rosin wrote:
* lib/ar-lib: Implement the q (quick) action as a synonym
for r (replace). Ignore s (symbol index) and S (no symbol
index) when used as modifiers and s when used as a command,
there is simply no way for
On 03/02/2012 10:37 AM, Peter Rosin wrote:
Stefano Lattarini skrev 2012-03-02 10:32:
On 03/01/2012 08:36 PM, Peter Rosin wrote:
* lib/ar-lib: Implement the q (quick) action as a synonym
for r (replace). Ignore s (symbol index) and S (no symbol
index) when used as modifiers and s when used
Stefano Lattarini skrev 2012-03-02 11:15:
On 03/02/2012 10:37 AM, Peter Rosin wrote:
Stefano Lattarini skrev 2012-03-02 10:32:
On 03/01/2012 08:36 PM, Peter Rosin wrote:
* lib/ar-lib: Implement the q (quick) action as a synonym
for r (replace). Ignore s (symbol index) and S (no symbol
1 - 100 of 296 matches
Mail list logo
