Discussion:
[Bug-apl] SVN ignore: part 2
Marcin Cieslak
2017-05-03 22:06:06 UTC
Permalink
The remaining files that are
autogenerated and - at the same time -
are included in the repository are:

m> svn status | grep '^M '
M Makefile
M Makefile.in
M aclocal.m4
M config.h
M config.h.in
M configure
M debian/Makefile.in
M debian/source/Makefile.in
M doc/Makefile.in
M erlang/Makefile.in
M gnu-apl.d/Makefile.in
M ltmain.sh
M m4/libtool.m4
M m4/ltoptions.m4
M m4/ltversion.m4
M rpm/Makefile.in
M src/APs/Makefile.in
M src/Makefile.in
M src/buildtag.hh
M src/emacs_mode/Makefile.in
M src/makefile.h
M src/native/Makefile.in
M src/sql/Makefile.in
M src/testcases/Makefile.in
M src/workspaces/Makefile.in
M support-files/105-key-International-Keyboard/Makefile.in
M support-files/Dirk/Makefile.in
M support-files/Dyalog-Keyboard/Makefile.in
M support-files/Makefile.in
M support-files/OS-X-Keyboard/Makefile.in
M support-files/Unicomp-Keyboard/Makefile.in
M support-files/WASD-Keyboard/Makefile.in
M support-files/old-Keyboard/Makefile.in
M tools/Makefile.in
M workspaces/Makefile.in
M wslib3/Makefile.in
M wslib4/Makefile.in
M wslib5/APLComponentFiles/Makefile.in
M wslib5/Makefile.in
M wslib5/iso-apl-cf/Makefile.in


Most of those files (configure, Makefile.in)
are autogenerated by automake and modified
after running autoreconf

I think they also should be removed from the SVN repository
and ignored there (added to the svn:ignore property).

People running GNU APL from SVN should do "autoreconf"
prior to trying to build it.

In the release tarball they should be included - release
users should be able just to run ./configure

I will also have a look at the way

src/buildtag.hh
src/makefile.h
src/configure_args.cc

are generated - I think we could generate them using automake
instead. This way an out-of-tree build could work again.

Marcin Cieślak
Alexey Veretennikov
2017-05-04 06:27:13 UTC
Permalink
Hi,

The current way to distribute GNU APL is via SVN for good or bad.
On some systems where is no support for autoreconf but ./configure works
perfectly fine.
Please don't enforce people to run autoreconf on GNU APL from SVN.
Post by Marcin Cieslak
People running GNU APL from SVN should do "autoreconf"
prior to trying to build it.
--
Br,
/Alexey
Blake McBride
2017-05-04 11:14:08 UTC
Permalink
On Thu, May 4, 2017 at 1:27 AM, Alexey Veretennikov <
Post by Alexey Veretennikov
...
Please don't enforce people to run autoreconf on GNU APL from SVN.
I second that!

Blake
Juergen Sauermann
2017-05-04 10:35:51 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=iso-8859-2"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Marcin,<br>
<br>
actually all these files are in the GNU APL tar file which is
generated by <b>make dist</b>.<br>
The SVN repository is simply the unpacked tar file, provided for
convenience.<br>
<br>
It was mainly either  <b>automake</b> or <b>autoconf</b> which
decided that these files should go into the tar<br>
file produced by <b>make dist</b>, and I believe those who have
developed <b>autoconf/automake </b>know<br>
better than me why these files are in the tar file (and are
therefore also in the SVN repository).<br>
<br>
If you remove, for example, all the <b>Makefile.in</b> files,
then <b>./configure</b> does not work anymore.<br>
You then need to install <b>autoconf</b>, which is not installed
by default on most recent GNU/Linux<br>
machines.<br>
<br>
The strategy of GNU APL is to depend on as few other packages as
possible, even at the price of<br>
a few more files. I know that these redundant files create a few
nasty svn warnings when updating<br>
from SVN, but SVN has command line options (like <b>--accept tc</b>)
to prevent them.<br>
<br>
Best regards,<br>
Jürgen Sauermann<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 05/04/2017 12:06 AM, Marcin Cieslak
wrote:<br>
</div>
<blockquote
cite="mid:***@z.fncre.vasb"
type="cite">
<pre wrap="">The remaining files that are
autogenerated and - at the same time -
are included in the repository are:

m&gt; svn status | grep '^M '
M Makefile
M Makefile.in
M aclocal.m4
M config.h
M config.h.in
M configure
M debian/Makefile.in
M debian/source/Makefile.in
M doc/Makefile.in
M erlang/Makefile.in
M gnu-apl.d/Makefile.in
M ltmain.sh
M m4/libtool.m4
M m4/ltoptions.m4
M m4/ltversion.m4
M rpm/Makefile.in
M src/APs/Makefile.in
M src/Makefile.in
M src/buildtag.hh
M src/emacs_mode/Makefile.in
M src/makefile.h
M src/native/Makefile.in
M src/sql/Makefile.in
M src/testcases/Makefile.in
M src/workspaces/Makefile.in
M support-files/105-key-International-Keyboard/Makefile.in
M support-files/Dirk/Makefile.in
M support-files/Dyalog-Keyboard/Makefile.in
M support-files/Makefile.in
M support-files/OS-X-Keyboard/Makefile.in
M support-files/Unicomp-Keyboard/Makefile.in
M support-files/WASD-Keyboard/Makefile.in
M support-files/old-Keyboard/Makefile.in
M tools/Makefile.in
M workspaces/Makefile.in
M wslib3/Makefile.in
M wslib4/Makefile.in
M wslib5/APLComponentFiles/Makefile.in
M wslib5/Makefile.in
M wslib5/iso-apl-cf/Makefile.in


Most of those files (configure, Makefile.in)
are autogenerated by automake and modified
after running autoreconf

I think they also should be removed from the SVN repository
and ignored there (added to the svn:ignore property).

People running GNU APL from SVN should do "autoreconf"
prior to trying to build it.

In the release tarball they should be included - release
users should be able just to run ./configure

I will also have a look at the way

src/buildtag.hh
src/makefile.h
src/configure_args.cc

are generated - I think we could generate them using automake
instead. This way an out-of-tree build could work again.

Marcin Cieślak


</pre>
</blockquote>
<br>
</body>
</html>
Leslie S Satenstein
2017-05-04 14:32:25 UTC
Permalink
Here is a simple scenario.
LIBREF-0 /home/group/project1
With several users writing code for project1
User A issues a command )Continue and goes to lunchUser B issues a command )Continue and goes to lunchUser C issues a command )Continue and goes to lunch
Who went last was the one whose )Continue was created for A, B, C
Information for the other than last )Continue was overwrittenAnother possibility is that of A,B,C , two of them could have been saving or dropping )Continue
This question is only a problem if LIBREF-0 is a shared library.  It is likely that it is shared. -- How so?
I have the LIBREF-0 as pointing to my  /home/Dropbox/APLarea.  I have access to Dropbox from multiple systems.
My view is that sometime in the future, we should consider that gnu-apl's  )Continue be stored privately within a
/home/logonid/.gnu-apl   or as /home/logonid./apl-continue.xml

Just some thoughts from an old Geezer who was an APL biggot beginning 1972
 Leslie
Leslie Satenstein
Montréal Québec, Canada
My first use of APL inhouse
Juergen Sauermann
2017-05-04 16:24:47 UTC
Permalink
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Leslie,<br>
<br>
traditionally LIBREF-0 aka. the default library, has been assumed
to be a non-shared library.<br>
The reason is that:<br>
<br>
1. You need at least one non-shared (i.e per user) library.
Exactly for storing the )CONTINUE workspace, and<br>
2. many users (or at least myself) do not set up additional
libraries.<br>
<br>
</font>I just tested IBM APL2 (PC version) and they also store the
CONTIUNUE workspace in the default library.<br>
Their library tree lives in a somewhat odd place: <b>C:\Program
Files/ibmapl2w</b>. This roughly corresponds<br>
to something like <b>/usr/bin/ibmaplw</b> on GNU/Linux and would
violate the file system hierarchy standard<br>
(FHS). You also get the same behavior that you describe below.
Except that Windows is not normally used by<br>
different users.<br>
<br>
So IBM APL2 uses <b>C:\Program Files/ibmapl2w\</b> for what is
called the library root in GNU APL and uses<br>
the following fixed (non-configurable) mapping between library
numbers and the sub directories of the lib root:<br>
<br>
0: bin<br>
1: wslib1<br>
2: wslib2<br>
<br>
GNU APL has adopted the naming (read: wslibN) of IBM APL2, but with
the following changes:<br>
<br>
* use <b>workspace</b> instead of <b>bin</b>,<br>
* use <b>10</b> lib numbers instead of <b>3</b>, and<br>
* make every library number configurable so that the user has full
control over where the libraries live.<br>
<br>
It may be that IBM APL2 supports more than 2 wslib directories but
only 2 are being installed by<br>
IBM APL2. In those they store some workspaces shipped with IBM APL2.
I would say that the IBM lib<br>
numbers 1 and 2 roughly correspnd to GNU APL lib numbers 3, 4, and 5
in that they are used for<br>
workspaces shipped with GNU APL.<br>
<br>
The cool thing in your Dropbox setup is that you can say )CONTINUE
on one machine and continue<br>
later on another machine. To me that looks more like a feature than
a bug and you can easily<br>
configure otherwise if you don't like the feature.<br>
<br>
I would also assume that the scenario below only works if A, B, and
C  are logged in on the same<br>
machine or network under the same user name, because otherwise they
would get an error instead<br>
of overriding each other's CONTINUE workspace files.<br>
<br>
<br>
Best Regards,<br>
/// Jürgen<br>
<br>
<br>
<div class="moz-cite-prefix">On 05/04/2017 04:32 PM, Leslie S
Satenstein wrote:<br>
</div>
<blockquote
cite="mid:***@mail.yahoo.com"
type="cite">
<div style="color:#000; background-color:#fff;
font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande,
sans-serif;font-size:13px">
<div id="yui_3_16_0_ym19_1_1493904418141_25954"><span>Here is a
simple scenario.</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_25955"><span><br>
</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_25956"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">LIBREF-0
/home/group/project1</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_25970"><span
id="yui_3_16_0_ym19_1_1493904418141_25964"><br>
</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26099"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">With several
users writing code for project1</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26100"><span
id="yui_3_16_0_ym19_1_1493904418141_25964"><br>
</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26129"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">User A issues a
command )Continue and goes to lunch</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26148"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">User B issues a
command )Continue and goes to lunch</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26175"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">User C issues a
command )Continue and goes to lunch</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26174"><span
id="yui_3_16_0_ym19_1_1493904418141_25964"><br>
</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26164"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">Who went last was
the one whose )Continue was created for A, B, C <br>
</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26173"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">Information for
the other than last )Continue was overwritten</span></div>
<div dir="ltr" id="yui_3_16_0_ym19_1_1493904418141_26165"><span
id="yui_3_16_0_ym19_1_1493904418141_25964">Another
possibility is that of A,B,C , two of them could have been
saving or dropping )Continue</span></div>
<div dir="ltr"><span id="yui_3_16_0_ym19_1_1493904418141_25964"><br>
</span></div>
<div dir="ltr"><span id="yui_3_16_0_ym19_1_1493904418141_25964"></span>
This question is only a problem if LIBREF-0 is a shared
library.  It is likely that it is shared. -- How so?</div>
<div dir="ltr" id="yui_3_16_0_ym19_1_1493904418141_26176"><br>
</div>
<div dir="ltr" id="yui_3_16_0_ym19_1_1493904418141_26177">I have
the LIBREF-0 as pointing to my  /home/Dropbox/APLarea.  I have
access to Dropbox from multiple systems.</div>
<div dir="ltr" id="yui_3_16_0_ym19_1_1493904418141_26178"><br>
</div>
<div dir="ltr" id="yui_3_16_0_ym19_1_1493904418141_26287">My
view is that sometime in the future, we should consider that
gnu-apl's  )Continue be stored privately within a <br>
</div>
<div dir="ltr" id="yui_3_16_0_ym19_1_1493904418141_26286">/home/logonid/.gnu-apl  
or as /home/logonid./apl-continue.xml <br>
</div>
<div class="signature"
id="yui_3_16_0_ym19_1_1493904418141_25712">
<div id="yui_3_16_0_ym19_1_1493904418141_25711">
<div id="yui_3_16_0_ym19_1_1493904418141_25710">
<div id="yui_3_16_0_ym19_1_1493904418141_25709">
<div id="yui_3_16_0_ym19_1_1493904418141_25708">
<div id="yui_3_16_0_ym19_1_1493904418141_25707">
<div id="yui_3_16_0_ym19_1_1493904418141_25706">
<div id="yui_3_16_0_ym19_1_1493904418141_25705">
<div id="yui_3_16_0_ym19_1_1493904418141_26288"><span
style="" lang="FR-CA"><br>
</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26222"><span
style=""
id="yui_3_16_0_ym19_1_1493904418141_26285"
lang="FR-CA">Just some thoughts from an old
Geezer who was an APL biggot beginning 1972</span></div>
<div id="yui_3_16_0_ym19_1_1493904418141_26350"><br>
</div>
<div id="yui_3_16_0_ym19_1_1493904418141_25763"><b
id="yui_3_16_0_ym19_1_1493904418141_26268"><font
id="yui_3_16_0_ym19_1_1493904418141_26267"
size="2"> Leslie</font><br>
</b></div>
<div id="yui_3_16_0_ym19_1_1493904418141_25704"><font
id="yui_3_16_0_ym19_1_1493904418141_26270"
color="green"><b
id="yui_3_16_0_ym19_1_1493904418141_26269"><font
size="1">Leslie Satenstein</font></b></font><font
style="color:rgb(191, 0, 95);" color="green"
size="1"><span style="font-weight:bold;"></span></font><br>
</div>
<font id="yui_3_16_0_ym19_1_1493904418141_26266"
color="green" size="2"><b
id="yui_3_16_0_ym19_1_1493904418141_26265">Montréal
Québec, Canada</b><br>
</font>My first use of APL inhouse <br>
<font face="lucida console, sans-serif" size="1"><b
id="yui_3_13_0_ym1_1_1391351152837_28311"><font
id="yui_3_13_0_ym1_1_1391351152837_28310"
color="black"><span
id="yui_3_13_0_ym1_1_1391351152837_28309"
style="font-weight:bold;font-size:13.5pt;color:black;"></span></font></b></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>
Marcin Cieslak
2017-05-04 20:10:28 UTC
Permalink
Post by Juergen Sauermann
Hi Marcin,
actually all these files are in the GNU APL tar file which is generated by make dist.
The SVN repository is simply the unpacked tar file, provided for convenience.
It was mainly either  automake or autoconf which decided that these files should go into the tar
file produced by make dist, and I believe those who have developed autoconf/automake know
better than me why these files are in the tar file (and are therefore also in the SVN repository).
No problem. Of course there are ways to deal with this but if you intend to keep
the SVN as a kind of snapshot of everything that is of course better.

I wasn't sure if this was intended or not.

Thank you for your response and thanks for keeping GNU APL alive!

Marcin

Continue reading on narkive:
Loading...