tack-devel — Discussion for developers of the ACK.

Re: [Tack-devel] Prime Mover commands

[David G. <dg...@co...>]

tim kelly wrote:
[...]
> What happens in a large build, like a kernel or userland worldbuild, wh=
ere
> the .o files can number into the hundreds and even thousands of files,
> normally distributed throughout the build tree?
[...]
> Using ls -a /tmp/ack-temp/pmcache > temp.txt and determining the number=
 of
> lines in temp.txt, the pmcache directory for ACK appears to have 1931
> items.

That's correct. In fact, current head-of-CVS ACK has (I just counted
them) 6684 temporary files!

In fact, this is not a problem. Modern filesystems cope just fine with
lots of files in one directory (see
http://www.namesys.com/faq.html#optimaldirstruct), but if this ever
becomes a restriction it would be trivial to modify pm to use a
hierarchical structure to reduce the number of files in the directory,
in much the same way Squid does.

pm actually keys its intermediate files against the command that was
used to build them. An alternative implementation would be to replace
the numerical ID with the command string itself (with slashes replaced);
this would work just as well, although the pathnames would get rather
big. (It might even be faster.)

[...]
> ext_cfile =3D simple_with_clike_dependencies {
>=20
>         class =3D "ext_cfile",
>         outputs =3D {o.."%U%-%I%.o"},
>         inputs =3D inputs..".c",
>         inputs =3D d..inputs,
> }
[...]
> which would allow building 4A and 4B seperately, without building defau=
lt.
> The ext_cfile won't run, of course, because the concatentation doesn't =
work
> (I'm not up to speed on modifying inputs yet), but overall the goal wou=
ld
> be to simplify specifying target source file and object file.  Not that=

> it's complicated; I'm just trying to reduce the amount of typing and nu=
mber
> of characters in the pmfile for ease of reading.

Firstly, .. is a Lua operator that only has an effect when the pmfile is
read. What your o.."%U%-%I%.o" will do above is to do the concatenation
*while defining ext_cfile*, rather than when the ext_cfile rule runs.
This sort of thing is what the {PARENT, "foo"} construction is for.
Ugly, I know, but I couldn't come up with anything else.

Secondly, you can't modify a rule's inputs, because they're not strings!
They're references to other rules. This:

    cfile "foo.c"

=2E..is actually syntactic sugar for:

    cfile {
        file {"foo.c"}
    }

=2E..that is, a cfile rule that depends on a static reference to a file.

If you want to do this kind of thing you have to pass the information
into the rule in a variable, and then refer to a file via the variable
name --- the example I posted a link to does this.

(It's also possible to do this without subclassing a rule at all. The
exported-o rule in the example could be written as:

exported_o =3D group {
    class =3D "exported_o",
    cfile {
        CBUILDFLAGS =3D {PARENT, "-O%OPTIMISATION%"},
        install =3D pm.install("%DESTDIR%%BASE%-O%OPTIMISATION%.o"),
        file "%SRCDIR%%BASE%.c"
    }
}

Does that make it clearer what's going on?)

>> I also found a bug in c.pm, so you'll need a new version of that as we=
ll if
>> you want rebuilding to work properly.]
>=20
> Ok, thanks for the heads up.  Unfortunately, at least on NetBSD, Subver=
sion
> (svn) requires Apache Portable Runtime, which appears to require instal=
ling
> Apache httpd, which I don't see a need to do, so I have not yet been ab=
le
> to sync up to files committed to the subversion tree at sourceforge.

I use Eclipse with the Subclipse plugin; it's got a pure-Java
implementation of the Subversion protocol and works very well. Of
course, this is probably a little heavyweight unless you're using
Eclipse for other purposes... but in emergencies, you can always pull
individual files out of Sourceforge's SVN browser:

http://svn.sourceforge.net/viewvc/primemover

BTW, I've created a Prime Mover mailing list to avoid spamming all the
other people on the ACK list. See:

http://sourceforge.net/mail/?group_id=3D157791

I think we'd probably better relocate there before everyone else
unsubscribes from tack-devel...

--=20
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg...@co...    | until you have read it in the original Klingon."
| (dg...@ta...) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

At 6:56 PM -0400 8/2/06, David Given wrote:
>Unfortunately, that's not what the intermediate cache is for --- it's not the
>final destination of the built files, it's where pm stores (for its own
>nefarious purposes) the *intermediate files* it uses to build things. It's not
>supposed to be public, which is why it defaults to a hidden directory. (In
>fact, the only reason the files in there have human-readable names is to make
>debugging easier. The first version called everything 1.o, 2.o, 3.o, 4.a,
>etc.)

What happens in a large build, like a kernel or userland worldbuild, where
the .o files can number into the hundreds and even thousands of files,
normally distributed throughout the build tree?  If the intermediate cache
is the location for all of these, and the README for pm indicates that the
intermediate cache is used to speed building (using the indexing), this
centralized location is going to be extremely full.

Using ls -a /tmp/ack-temp/pmcache > temp.txt and determining the number of
lines in temp.txt, the pmcache directory for ACK appears to have 1931
items.

I've done some reading on incremental linking (ild) and even got my local
library to get me a copy of Russel Quong and Mark Linton's seminal paper on
incremental linking, in order to research techniques to decrease
compilation time.  I'm in favor of your solution to use an intermediate
cache, and I like the idea of indexing the builds, but if the intermediate
cache is flat instead of hierarchical, this makes me concerned about larger
builds as described above.  Given the number of files from the ACK build, a
userland world build would be staggering.

>From my perspective, I don't mind having the indexed .o files in my
designated object directory; others might find it better to have only the
actual .o files used to create the final executable residing in their
object directory.  A hierarchical intermediate cache could meet both needs.


Is it possible to modify outputs for cfile somewhat like:

ext_cfile = cfile {
        class = "ext_cfile",
        outputs = {"lib/libsa/%U%-%I%.o"},
}

so that the cached files can have relative paths?

>If you want access to anything pm makes, you have to export it using 'install
>= pm.install()'. If you want access to all .o files, you should be able to do
>this by subclassing the cfile{} rule.
>
>[long example removed --- it actually turned out to be more interesting than I
>expected, so I checked it in. See:
>
>http://svn.sourceforge.net/viewvc/*checkout*/primemover/pm/test-pmfiles/complex
>-c-program.pm?revision=33

This example to me helps justify extending the cfile definition to
facilitate adding objects separate from groups.  There are two cfiles that
add test4.c, with different CDEFINES, but in order to build either one the
entire program has to be built.  The alternative pmfile I would envision
would be something akin to:

include "lib/c.pm"

local d = "test-source/"

ext_cfile = simple_with_clike_dependencies {

        class = "ext_cfile",
        outputs = {o.."%U%-%I%.o"},
        inputs = inputs..".c",
        inputs = d..inputs,
}


test = ext_cfile ("test")
test1 = ext_cfile ("test1")
test2 = ext_cfile ("test2")
test3 = ext_cfile ("test3")

-- Compile these two files with a modified definition of CDEFINES ---
-- they should get both test1 and test4 defined.

test4A = ext_cfile {
            CDEFINES = {PARENT, "-Dtest4=test4A"},
           "test4",
},

test4B = ext_cfile {
           CDEFINES = {PARENT, "-Dtest4=test4B"},
           "test4",
},

default = cprogram {
          CDEFINES = {"-Dtest1=fnord"},

           test,
           test1,
           test2,
           test3,
           test4A,
           test4B,

           install = pm.install("test-source/complex-c-program")
}

which would allow building 4A and 4B seperately, without building default.
The ext_cfile won't run, of course, because the concatentation doesn't work
(I'm not up to speed on modifying inputs yet), but overall the goal would
be to simplify specifying target source file and object file.  Not that
it's complicated; I'm just trying to reduce the amount of typing and number
of characters in the pmfile for ease of reading.

>I also found a bug in c.pm, so you'll need a new version of that as well if
>you want rebuilding to work properly.]

Ok, thanks for the heads up.  Unfortunately, at least on NetBSD, Subversion
(svn) requires Apache Portable Runtime, which appears to require installing
Apache httpd, which I don't see a need to do, so I have not yet been able
to sync up to files committed to the subversion tree at sourceforge.

>> How do I do a "Save and Restore" for the pm.intermediate_cache_dir setting,
>> so that it is local in scope wrt to the pmfile, or even the object being
>> built?
>
>You can't, I'm afraid --- once execution of your pmfile script has finished,
>whatever value you last set it as sticks. It *might* be possible to trick pm
>into running code where you change it, but all that's likely to happen is
>horribly confusing pm.

Then perhaps the pmcache/outputs connection could be modified to be more
hierarchical.  Just a thought.

thanks,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[David G. <dg...@co...>]

tim kelly wrote:
[...]
>> pm.intermediatecache =3D o
>=20
> I did some digging into the pm script in the Subversion web interface a=
nd
> found that this perhaps should be pm.intermediate_cache_dir, which seem=
s to
> give the desired results.

Oops! Sorry --- I should know better than to trust my memory late at nigh=
t...

[...]
> I really like the INDEX principle, by the way.  I do a lot of "objdump =
-d"s
> on object files, so having something that caches the builds allows me t=
o
> compare changes between flags (like -On) much easier.  It also undersco=
res
> the need for being able to change the intermediate cache directory, so =
that
> instead of all of the cached object files going into a single directory=
, a
> shadow object file tree can be constructed for easier traversal.

Unfortunately, that's not what the intermediate cache is for --- it's not=
 the
final destination of the built files, it's where pm stores (for its own
nefarious purposes) the *intermediate files* it uses to build things. It'=
s not
supposed to be public, which is why it defaults to a hidden directory. (I=
n
fact, the only reason the files in there have human-readable names is to =
make
debugging easier. The first version called everything 1.o, 2.o, 3.o, 4.a,=
 etc.)

If you want access to anything pm makes, you have to export it using 'ins=
tall
=3D pm.install()'. If you want access to all .o files, you should be able=
 to do
this by subclassing the cfile{} rule.

[long example removed --- it actually turned out to be more interesting t=
han I
expected, so I checked it in. See:

http://svn.sourceforge.net/viewvc/*checkout*/primemover/pm/test-pmfiles/c=
omplex-c-program.pm?revision=3D33

I also found a bug in c.pm, so you'll need a new version of that as well =
if
you want rebuilding to work properly.]

> How do I do a "Save and Restore" for the pm.intermediate_cache_dir sett=
ing,
> so that it is local in scope wrt to the pmfile, or even the object bein=
g
> built?

You can't, I'm afraid --- once execution of your pmfile script has finish=
ed,
whatever value you last set it as sticks. It *might* be possible to trick=
 pm
into running code where you change it, but all that's likely to happen is=

horribly confusing pm.

> This, of course,
> brings up a question I've had regarding threaded builds, equivalent to =
make
> -Jn where n is the number of threads (which also invokes stuff like .WA=
IT
> and the like).

Currently not on the drawing boards... sorry! pm guarantees the order in =
which
things are built (nodes are recursed into in strict depth-first order) wh=
ich
means threaded builds would be Really Hard. However, if you build with -p=
ipe
you should get most of the benefits of having a multiprocessor machine wi=
thout
needing them.

--=20
+- David Given --McQ-+ "Gaping from its single obling socket was
|  dg...@co...    | scintillating, many fauceted scarlet emerald..."
| (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)

[Tack-devel] More questions regarding intermediate_cache_dir

[tim k. <gt...@di...>]

At 5:11 PM -0400 8/2/06, tim kelly wrote:
>I did some digging into the pm script in the Subversion web interface and
>found that this perhaps should be pm.intermediate_cache_dir, which seems to
>give the desired results.  I have an error occuring regarding not finding a
>file, but I think that is something I've done, as I did get a .o file and
>an INDEX file in the new directory.

How do I do a "Save and Restore" for the pm.intermediate_cache_dir setting,
so that it is local in scope wrt to the pmfile, or even the object being
built?  Do I set this within the cfile description?  Should
intermediate_cache_dir be a property of cfiles? I'm assuming the the
instance of pm is global and not on a per pmfile basis.  This, of course,
brings up a question I've had regarding threaded builds, equivalent to make
-Jn where n is the number of threads (which also invokes stuff like .WAIT
and the like).

thanks in advance,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

At 8:01 PM -0400 7/31/06, tim kelly wrote:
>At 7:15 AM -0400 7/31/06, David Given wrote:
>>> 3)  As another feature request, can the cache directory no longer default
>>> to a "." directory?  Sometimes I forget the cache directory is hidden, and
>>> while at least with OpenBSD "ls" does automatically -a, not all systems do.
>>
>>Put:
>>
>>pm.intermediatecache = "path"
>>
>>...in your pmfile. (The ACK config.pm does this.)
>
>This did not work for me, unfortunately.
>
>./.pm-exec-macppc: stdin:71: Attempt to write to new global intermediatecache
>stack traceback:
>        [C]: in function `error'
>        stdin:71: in function <stdin:70>
>        lib/libsa/pmfile:12: in function `c'
>        stdin:937: in function `include'
>        pmfile:16: in function `c'
>        stdin:1524: in main chunk
>        [C]: ?
>
>The local pmfile:
>
>local o = OBJDIR.."lib/libsa/"
>
>pm.intermediatecache = o

I did some digging into the pm script in the Subversion web interface and
found that this perhaps should be pm.intermediate_cache_dir, which seems to
give the desired results.  I have an error occuring regarding not finding a
file, but I think that is something I've done, as I did get a .o file and
an INDEX file in the new directory.

I really like the INDEX principle, by the way.  I do a lot of "objdump -d"s
on object files, so having something that caches the builds allows me to
compare changes between flags (like -On) much easier.  It also underscores
the need for being able to change the intermediate cache directory, so that
instead of all of the cached object files going into a single directory, a
shadow object file tree can be constructed for easier traversal.

thanks,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

At 7:15 AM -0400 7/31/06, David Given wrote:
>> 3)  As another feature request, can the cache directory no longer default
>> to a "." directory?  Sometimes I forget the cache directory is hidden, and
>> while at least with OpenBSD "ls" does automatically -a, not all systems do.
>
>Put:
>
>pm.intermediatecache = "path"
>
>...in your pmfile. (The ACK config.pm does this.)

This did not work for me, unfortunately.

./.pm-exec-macppc: stdin:71: Attempt to write to new global intermediatecache
stack traceback:
        [C]: in function `error'
        stdin:71: in function <stdin:70>
        lib/libsa/pmfile:12: in function `c'
        stdin:937: in function `include'
        pmfile:16: in function `c'
        stdin:1524: in main chunk
        [C]: ?


The local pmfile:

local o = OBJDIR.."lib/libsa/"

pm.intermediatecache = o



On a different note, I would like to alter the default cfile behavior
slightly, but I am having some difficulty achieving my desired results.  I
wish to simplify the adding of files to pmfiles, such that I add a single
line naming the root of the .c file and both the source .c file and the
output .o file are created dynamically.  For example:

qdvirem = ext_cfile {"qdivrem"}

should know to look in the source code directory for qdivrem.c and to
output to the object directory qdivrem.o.  With the above syntax I can then
add qdivrem to a group while compiling it individually if I choose.

math = group {
            stuff,
            qdvirem,
            more_stuff,
}


I have been able to achieve basic results by overriding the cfile outputs
method at the time of the declaration of qdvirem:


qdvirem = cfile {d.."qdivrem.c"}, output = {o.."qdvirem.o"} }

but this is still unnecessarily verbose.  My attempts to override the
inputs to cfile are not succeeding:

local d = ROOTDIR.."lib/libsa/"

local o = OBJDIR.."lib/libsa/"

ext_cfile = cfile {
        class = "ext_cfile",
        outputs = {o.."%in%.o"},
        in = {d..%in%..".c"},
}

I have also attempted to modify the definition of cfile in c.pm, but I am
not getting anywhere there, either, as there is still the intermediate
cache location as the default.  I don't grok where U and I are defined,
also.

Any suggestions/advice are greatly appreciated (I did manage to get a shell
file executing to build the versioning information for the executable, a
small victory to cling to).

thanks in advance,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

At 7:15 AM -0400 7/31/06, David Given wrote:
>It's difficult to tell what's going on without seeing your code, but
>have you defined ROOTDIR as local? Local variables in Lua are
>fundamentally different things to global variables --- local variables
>are lexically scoped, and included scripts execute in a different scope
>and so won't see locals defined in the caller.

I see the problem now.  I had included the file that concatenates ROOTDIR
before I had defined ROOTDIR.  I was thinking the included pmfile (and its
local variables) wouldn't be evaluated until the target it contains is
built.

>> local d = ROOTDIR.."lib/libsa/"
>
>Because ROOTDIR here is used in a Lua expression, it'll get evaluated
>when the script is read, and so ROOTDIR must be defined before this line
>is seen. OTOH, if you were to say "%ROOTDIR%lib/libsa/" instead, then
>the %...% reference will only get expanded at the very last stage of
>execution, and will be looked up in the call stack of the rules
>currently being processed.

So using the %..% notation it is possible to temporarily repoint global
variables, and the actual value isn't used until the script actually
executes, correct?

>Sorry, pm doesn't necessarily have this information. However, if you
>were to put:
>
>print(somerule.VARIABLENAME)
>os.exit()

Ok, I'm a little slow on the uptake.  What should I use for "somerule?"
When explaining stuff to me, it is advisable to speak slowly and explictly;
otherwise I am likely to interpret what you say literally :-)

>Put:
>
>pm.intermediatecache = "path"
>
>...in your pmfile. (The ACK config.pm does this.)

Thanks!

>[...]
>> 4) Can I get some bare-bones description on differences between cfiles,
>> cprograms, clibraries, and other possible options?
>
>cfile compiles a single .c file into a single .o file. clibrary builds
>an ar archive out of its inputs. cprogram links all of its inputs
>together into an executable.

Thanks again!  Can I specify a single cfile as a target, if it is only
included in a larger group or cprogram?  Or do I need to have it as a
separate object?

>If you look in the pm Subversion repository, I've just checked in a
>bunch of test files in test-pmfiles and test-source --- you may find
>these useful to look at.

Excellent!  I will do this.  Is pm a top-level cvs module?

thanks again!
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[David G. <dg...@co...>]

tim kelly wrote:
[...]
> 1) With targets that are included via including their pmfiles, are the
> globals in the master pmfile evaluated?  I define ROOTDIR in the master=

> pmfile but when I try to build an included target, ROOTDIR is a nil poi=
nter:

Yes. The way pm works is that it reads in the specified pmfile and
executes it as a Lua script. This builds data structures in memory. When
the script returns, pm looks at these data structures and decides what
needs doing. (You can use pm as a general Lua scripting engine by
putting os.exit(0) in the script; this will cause pm to exit cleanly
without trying to do anything.)

It's difficult to tell what's going on without seeing your code, but
have you defined ROOTDIR as local? Local variables in Lua are
fundamentally different things to global variables --- local variables
are lexically scoped, and included scripts execute in a different scope
and so won't see locals defined in the caller.

(When the Lua compiler sees a reference to a name, it will first attempt
to find a local with that name, and if that fails it'll substitute the
equivalent of _G.name instead. That is, undefined names are turned into
dynamic references to the global dictionary. When pm does it's
hierarchical variable lookups, the global dictionary is the last place
it looks for anything.)

[...]
> local d =3D ROOTDIR.."lib/libsa/"

Because ROOTDIR here is used in a Lua expression, it'll get evaluated
when the script is read, and so ROOTDIR must be defined before this line
is seen. OTOH, if you were to say "%ROOTDIR%lib/libsa/" instead, then
the %...% reference will only get expanded at the very last stage of
execution, and will be looked up in the call stack of the rules
currently being processed.

> 2) Is there a flag that is the equivalent of -V in make to display the
> value of a variable?  If there is not, I would like to make a feature
> request to expand the -D flag, such that -D?X lists the first iterative=

> evaluation of X and -D??X lists the completely iterated evaluation of X=
=2E

Sorry, pm doesn't necessarily have this information. However, if you
were to put:

print(somerule.VARIABLENAME)
os.exit()

=2E..into a pmfile (called, say, debug.pm), and then do:

=2E/pm -f test.pm -f debug.pm

=2E..then the value of VARIABLENAME will be dumped without actually doing=

anything else. However, string expansion will not be done (as there is
no call stack to do it in).

> 3)  As another feature request, can the cache directory no longer defau=
lt
> to a "." directory?  Sometimes I forget the cache directory is hidden, =
and
> while at least with OpenBSD "ls" does automatically -a, not all systems=
 do.

Put:

pm.intermediatecache =3D "path"

=2E..in your pmfile. (The ACK config.pm does this.)

[...]
> 4) Can I get some bare-bones description on differences between cfiles,=

> cprograms, clibraries, and other possible options?

cfile compiles a single .c file into a single .o file. clibrary builds
an ar archive out of its inputs. cprogram links all of its inputs
together into an executable.

All this is in rather a state of flux right now --- for example, I've
just rewritten the way C dependencies are calculated to be a lot
friendlier to non-gcc compilers. In particular, the cryptic set of
variables used in the ACK's build mechanism for C programs is being
simplified drastically... it ought to be possible to simply add:

    CBUILDFLAGS =3D {PARENT, "-Osomething"},

=2E..into any rule and have it take effect for that rule *and* any rules
referred to by it... although I've just tried it and it's not working
quite right. I'll have a look later.

If you look in the pm Subversion repository, I've just checked in a
bunch of test files in test-pmfiles and test-source --- you may find
these useful to look at.

--=20
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg...@co...    | until you have read it in the original Klingon."
| (dg...@ta...) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+

[Tack-devel] Another CVS update

[David G. <dg...@co...>]

Good news, everyone! I now have nearly all the languages and the
language runtime libraries building in CVS. This includes both the K&R
and ANSI portable libcs.

Of course, I haven't done any of the syscall libraries yet, so you can't
actually build anything *useful*, but at least it's getting there. It
also takes quite a long time to build; given that each library has to be
built for each architecture (fewer than there used to be; I had to
disable some due to bugs), there are a lot of combinations. On my work
3.8GHz P4, it takes over five minutes to compile everything, and uses
59MB of temporary space.

Languages: K&R C, ANSI C, Pascal, Modula-2, Occam, Basic. No Fortran,
because that's just a preprocessor that makes C; and no Algol-68,
because the A68 compiler is written *in* A68 and can't be bootstrapped
with a C compiler.

Architectures: 6500, arm, i386, i80, i86, m68020, ns, z80, z8000. I had
to disable pdp and vax4 because of crashes while compiling the libc.
There's also something funny going on with the other 68000 variants. In
addition, trying to compile with -O4 causes odd problems --- haven't
sorted these out yet.

Next stop: the syscall libraries.

--=20
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg...@co...    | until you have read it in the original Klingon."
| (dg...@ta...) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

Hi,
I have some additional questions about Prime Mover, as I am using it to be
the build tool for the bootloader I've been modifying for the last couple
of years.

1) With targets that are included via including their pmfiles, are the
globals in the master pmfile evaluated?  I define ROOTDIR in the master
pmfile but when I try to build an included target, ROOTDIR is a nil pointer:

> ./pm -v libsa
./.pm-exec-macppc: lib/libsa/pmfile:5: attempt to concatenate global
`ROOTDIR' (a nil value)
stack traceback:
        lib/libsa/pmfile:5: in function `c'
        stdin:937: in function `include'
        pmfile:5: in function `c'
        stdin:1524: in main chunk
        [C]: ?

line 5 in lib/libsa/pmfile:

local d = ROOTDIR.."lib/libsa/"


2) Is there a flag that is the equivalent of -V in make to display the
value of a variable?  If there is not, I would like to make a feature
request to expand the -D flag, such that -D?X lists the first iterative
evaluation of X and -D??X lists the completely iterated evaluation of X.
For example,

-D?d in the above would yield ROOTDIR/lib/libsa and -D??d would fill in
ROOTDIR (including any included variables in ROOTDIR).


3)  As another feature request, can the cache directory no longer default
to a "." directory?  Sometimes I forget the cache directory is hidden, and
while at least with OpenBSD "ls" does automatically -a, not all systems do.


4) Can I get some bare-bones description on differences between cfiles,
cprograms, clibraries, and other possible options?  While much of these
objects is self-explanatory or available through reading the code, it would
be of use to me to have something I can refer to and/or analyze for
locations to do inheritence of those objects to more localized versions
with optimizations included.

thanks in advance,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

Hi David,

At 5:36 AM -0400 7/26/06, David Given wrote:
>[...]
>> ROOTDIR = ROOTDIR or posix.getcwd().."/"
>[...]
>>         cfile {
>>                 CBUILDFLAGS = CBUILDFLAGS or "-static -Winline -O3",
>
>Right; there's a rather confusing issue here that I'm still trying to
>come up with a clean way round it. Expressions such as 'a or b' are
>evaluated when the pmfile is read. Variables in %...% statements are
>looked up when the string is expanded. Your use of CBUILDFLAGS here will
>work but will override any variables defined further up the call tree.

That's ok, though, since I'm trying to leave an opening for specifying the
flags on the command line using the -D flag from pm.  If there are none
specified, then use the ones listed as default.

>(Variables, in CAPITAL LETTERS, are looked up via the call scope.
>Properties, in lower case, are not.) There's an idiom you can use for
>variable setting:
>
>	CBUILDFLAGS = {PARENT, "-static", "-Winline", "-O3"},
>
>This will cause the specified items to be apppended on to the list
>defined by the clause's callers.

I'm not sure exactly what the problem is, but this is not working for me:

> ./pm -p -fpmfile.memcopy
pm: creating new intermediate file cache in '.pm-cache/'
cc "-g" "-static" "-Winline" "-O3"     -MM -MG "~account/memcopy/main.c" >
".pm-cache/2-main.d"
cc "-g" "-static" "-Winline" "-O3"     -c -o ".pm-cache/1-main.o"
"/home/lapd/dW/memcopy/main.c"
cc "-g" "-static" "-Winline" "-O3"     -MM -MG
"~account/memcopy/fourbytes.s" > ".pm-cache/4-fourbytes.d"
as -mregnames -o ".pm-cache/3-fourbytes.o" "~account/memcopy/fourbytes.s"
cc "-g" "-static" "-Winline" "-O3"     -MM -MG
"~account/memcopy/sixteenbytes.s" > ".pm-cache/6-sixteenbytes.d"
as -mregnames -o ".pm-cache/5-sixteenbytes.o" "~account/memcopy/sixteenbytes.s"
./.pm-exec-macppc: stdin:143: bad argument #1 to `?' (string expected, got
table)
stack traceback:
        [C]: ?
        stdin:143: in function `rendertable'
        (tail call): ?
        [C]: ?
        stdin:757: in function `__expand'
        stdin:1287: in function `__outputs'
        stdin:673: in function `__build'
        stdin:647: in function `__buildchildren'
        stdin:667: in function `__build'
        stdin:1546: in main chunk
        [C]: ?

-- $Source: memcopy/pmfile,v $
-- $State: Exp $

include "c.pm"

ROOTDIR = ROOTDIR or posix.getcwd().."/"

local d = ROOTDIR

OBJDIR = OBJDIR or d.."obj/"

memcopy = cprogram {

        CBUILDFLAGS = {PARENT, "-static", "-Winline", "-O3"},

        cfile {
                d.."main.c",
        },

        afile {
                ASBUILDFLAGS = ASBUILDFLAGS or "-mregnames",
                d.."fourbytes.s",
        },

        afile {
                ASBUILDFLAGS = ASBUILDFLAGS or "-mregnames",
                d.."sixteenbytes.s",
        },

        outputs = {"%U%/memcopy"},
        install = {
                pm.install("%OBJDIR%memcopy"),
        }
}

default = group {
        memcopy,
}



Working under the impression this was supposed to work and the problem is
temporary or syntatic, can I do

              CBUILDFLAGS = CBUILDFLAGS or {PARENT, "-static", "-Winline",
"-O3"}

?  This actually builds, by the way, but does not seem to pick up the
default.  Additionally, can I specify from the command line a
-DCBUILDFLAGS={PARENT, "-Winline", "-O3"} in case I want to override the
defaults and not compile with static linking?

>Example:
>
>memcopy = cprogram {
>	CBUILDFLAGS = {PARENT, "-static", "-Winline", "-O3"},
>	ASBUILDFLAGS = {PARENT, "-mregnames"},
>
>	cfile (d.."main.c"),
>	afile (d.."fourbytes.s"),
>	afile (d.."sixteenbytes.s"),
>
>        outputs = {"%U%/memcopy"},
>        install = {
>                pm.install("%OBJDIR%memcopy"),
>        }
>}
>
>The definitions of CBUILDFLAGS and ASBUILDFLAGS will be *appended* to
>the defaults, and will apply to all clauses in the cprogram.

Sure, the application of inheritence is logical and why I think pm is an
easier tool to grasp than make.  I think it will make it easier to build
applications that build across OSes easier, instead of integrating against
bsd.*.mk files and the like.  It might require a bit more overhead in the
form of the c.pm files and a possibly an included copy of pm, but I'm
pretty frustrated with trying to track down integrated dependencies and I
do _not_ find make's syntax to be particularly transparent.

>[...]
>> I added the choice of compilers because I think it is important to be able
>> to have that choice.
>
>Yeah, the fact the pm only really likes gcc is an issue I need to deal
>with --- the tricky part is the dependency generation, for which there
>is no portable mechanism. I'm using gccisms. I may end up having to
>write a dependency calculator in Lua and build it into c.pm.

I think you should solve this.  It is my suspicion that some (perhaps all)
open source operating systems can't build on anything but the gcc
toolchain, which I find to be...shortsighted.  A build controller that can
make it transparent to move to other compiler setups would be really cool
and very likely embraced with enthusiasm.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[David G. <dg...@co...>]

tim kelly wrote:
(about pmfiles)

I'm impressed, given that the whole system is completely undocumented...

[...]
> ROOTDIR =3D ROOTDIR or posix.getcwd().."/"
[...]
>         cfile {
>                 CBUILDFLAGS =3D CBUILDFLAGS or "-static -Winline -O3",

Right; there's a rather confusing issue here that I'm still trying to
come up with a clean way round it. Expressions such as 'a or b' are
evaluated when the pmfile is read. Variables in %...% statements are
looked up when the string is expanded. Your use of CBUILDFLAGS here will
work but will override any variables defined further up the call tree.
(Variables, in CAPITAL LETTERS, are looked up via the call scope.
Properties, in lower case, are not.) There's an idiom you can use for
variable setting:

	CBUILDFLAGS =3D {PARENT, "-static", "-Winline", "-O3"},

This will cause the specified items to be apppended on to the list
defined by the clause's callers.

Example:

memcopy =3D cprogram {
	CBUILDFLAGS =3D {PARENT, "-static", "-Winline", "-O3"},
	ASBUILDFLAGS =3D {PARENT, "-mregnames"},

	cfile (d.."main.c"),
	afile (d.."fourbytes.s"),
	afile (d.."sixteenbytes.s"),

        outputs =3D {"%U%/memcopy"},
        install =3D {
                pm.install("%OBJDIR%memcopy"),
        }
}

The definitions of CBUILDFLAGS and ASBUILDFLAGS will be *appended* to
the defaults, and will apply to all clauses in the cprogram.

[...]
> I added the choice of compilers because I think it is important to be a=
ble
> to have that choice.

Yeah, the fact the pm only really likes gcc is an issue I need to deal
with --- the tricky part is the dependency generation, for which there
is no portable mechanism. I'm using gccisms. I may end up having to
write a dependency calculator in Lua and build it into c.pm.

[...]
> (Gee, any thoughts of a Makefile->pmfile converter?)

*twitch*

--=20
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg...@co...    | until you have read it in the original Klingon."
| (dg...@ta...) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

At 8:06 PM -0400 7/25/06, tim kelly wrote:
>Much of the parts are self-explanatory, and I'll post once I get the
>complete pmfile working (I've already added afile with command "%AS%" where
>AS = as).

-- $Source: memcopy/pmfile,v $
-- $State: Exp $

include "c.pm"

ROOTDIR = ROOTDIR or posix.getcwd().."/"

local d = ROOTDIR

OBJDIR = OBJDIR or d.."obj/"

memcopy = cprogram {


        cfile {
                CBUILDFLAGS = CBUILDFLAGS or "-static -Winline -O3",
                d.."main.c",
        },

        afile {
                ASBUILDFLAGS = ASBUILDFLAGS or "-mregnames",
                d.."fourbytes.s",
        },

        afile {
                ASBUILDFLAGS = ASBUILDFLAGS or "-mregnames",
                d.."sixteenbytes.s",
        },

        outputs = {"%U%/memcopy"},
        install = {
                pm.install("%OBJDIR%memcopy"),
        }
}

default = group {
        memcopy,
}


The ASBUILDFLAGS are working, but the CBUILDFLAGS aren't located properly,
I think, as the code isn't statically linking the libc library.

I did modify the c.pm file in a few places:

CCOMPILER = CCOMPILER or "cc"


ASCOMPILER = ASCOMPILER or "as"
AS = "%ASCOMPILER% %ASBUILDFLAGS% -o %out% %in%"

afile = simple_with_clike_dependencies {
        class = "afile",
        command = {"%AS%"},
        outputs = {"%U%-%I%.o"},
}

I added the choice of compilers because I think it is important to be able
to have that choice.

Overall I found this to be pretty straightforward, since the work is done
through inheritence and it's just a matter of describing the objects in the
pmfiles.  I am going to work on the original project I've been wrestling
with and I'll post something when I get it completely contained by pm.  I
really appreciate how clear the error messages were.  The above pmfile
could still be tweaked to do individual component building and then build
the program through the group object, instead of having it all in a single
cprogram, although I haven't gone through that yet.

(Gee, any thoughts of a Makefile->pmfile converter?)

thanks!
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

At 2:08 PM -0400 7/25/06, tim kelly wrote:
>Where's a good place to start?

I'll answer my own question -

Ack/first/c.pm
Ack/config.pm
LLgen/pmfile (simplest complete pmfile I've found)

Much of the parts are self-explanatory, and I'll post once I get the
complete pmfile working (I've already added afile with command "%AS%" where
AS = as).

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

Ok, so I took a look at some of the pmfiles and the Makefile on the project
I'm wanting to attempt to build and decided to move to a much simpler
project until I get the hang of pm.  I have some questions:

The application I'm building has three files, one is a C file and two are
assembly files.  Additionally, the as needs to see -mrenames as a flag
during the build process.  Here is the Makefile:

SHELL=  /bin/sh
SRC_PATH?=      ${PWD}/
PROG=   memcopy

OBJ_PATH= ${SRC_PATH}obj/
#OBJS=  fourbytes.o non-aligned.main.o sixteenbytes.o
OBJS=   main.o fourbytes.o sixteenbytes.o

CC?=    cc
#CFLAGS= -static -Winline -O3
CFLAGS= -Winline -O3
LD?=    ld
LDFLAGS=
AS?=    as
ASFLAGS= -mregnames

all: ${PROG}

${PROG}:  ${OBJS}
        ${CC} ${CFLAGS} -o ${PROG} $(OBJS)

main.o: main.c
        ${CC} ${CFLAGS} -c ${SRC_PATH}main.c >  ${OBJ_PATH}main.o

fourbytes.o: fourbytes.s
        ${AS} ${ASFLAGS} -o ${OBJ_PATH}fourbytes.o ${SRC_PATH}fourbytes.s

sixteenbytes.o: sixteenbytes.s
        ${AS} ${ASFLAGS} -o ${OBJ_PATH}sixteenbytes.o \
                                        ${SRC_PATH}sixteenbytes.s

clean:
        rm -f ${OBJ_PATH}*.o

.PHONY: clean

which actually doesn't work as is.  The PWD variable oddly gets the
directory wrong, but I have altered it to read how I think the path should
be determined for SRC_PATH (typically the current working directory).  I
don't actually reference ld, so that can be ignored.

Where's a good place to start?

thanks in advance,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] CVS & the new build system

[tim k. <gt...@di...>]

At 5:23 PM -0400 7/23/06, David Given wrote:
>Gregory T. (tim) Kelly wrote:
>[...]
>> The pmfiles seem quite a bit easier to read than Makefiles.  Do I need to
>> start learning some of this "Extended Context Free syntax" I read about in
>> the LLgen parser generator document?  :-)
>
>Actually, pmfiles are just Lua scripts --- see www.lua.org. LLgen is a tool
>used by the ACK to process grammars; it's very much like yacc or bison. It's
>not used by pm at all.

This lua stuff looks interesting, and the MIT license is very friendly.  I
have a project I've been trying to decouple from the OpenBSD and NetBSD
code trees, and I think I'll try out making it compile with Prime Mover as
the build tool (instead of make).  I'll let you know how it goes :-)

thanks,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

[Tack-devel] Linux install problems.

[r. c. <rvc...@ac...>]

I'm trying to install the cvs ack on debian testing (updated weekly)
and ran into a few problems:

 - first/create_dir does this

     mkdir $1 2>/dev/null

   to create directory $1.  By default mkdir doesn't create
   directories other than the last one; the preceding directories
   must exist:

     $ mkdir /tmp/a/b/c
     mkdir: cannot create directory `/tmp/a/b/c': No such file or directory

   This can be fixed by using the -p option to mkdir:

     $ rm -rf /tmp/a ; mkdir -p /tmp/a/b/c ; ls /tmp/a/b/c

     $

   Or by using install -d:

     $ rm -rf /tmp/a ; install -d /tmp/a/b/c ; ls /tmp/a/b/c

     $

   I don't know which of these is more portable.

 - first/mk_config does this

     for i in lang/cem/cemcom.ansi lang/cem/cemcom lang/m2/comp
     do
	     cp $SRC_HOME/$i/BigPars $CONFIG/$i/Parameters
	     chmod +w $CONFIG/$i/Parameters
     done

   but it doesn't create $CONFIG/$i/Parameters, which causes erorrs:

     cp: cannot create regular file
     `/tmp/ack/lang/cem/cemcom.ansi/Parameters': No such file or
     directory 

   This can be fixed by

     for i in lang/cem/cemcom.ansi lang/cem/cemcom lang/m2/comp
     do
             create_dir $CONFIG/$i/Parameters
	     cp $SRC_HOME/$i/BigPars $CONFIG/$i/Parameters
	     chmod +w $CONFIG/$i/Parameters
     done

   (I'm assuming Parameters is BigPars's parent directory).  This fix
   has to be applied to both for loops, the second of which isn't
   shown here.

 - INSTALL does this

     (
        # Slight complication here to ensure that the #! magic at the
        # beginning of TakeAction is preserved correctly.

        head -1 $SRC_HOME/TakeAction
        echo "PATH=:$CONFIG/bin:$UTIL_HOME/bin:$PATH; export PATH"
        tail +2 $SRC_HOME/TakeAction
     ) > $CONFIG/bin/TakeAction

   For whatever reason, using tail +n tail is frowned upon:

     $ tail +3 /dev/null
     Warning: "+number" syntax is deprecated, please use "-n +number"

     $

   The code works, but it's noisy.  It can be quieted by following
   the warning, or by 

     sed '2,$d' < $SRC_HOME/TakeAction
     echo "PATH=:$CONFIG/bin:$UTIL_HOME/bin:$PATH; export PATH"
     sed '1d' < $SRC_HOME/TakeAction

   or by (which replaces all the code given above)

     awk 'NR == 2 {
            write "PATH=:$CONFIG/bin:$UTIL_HOME/bin:$PATH; export PATH"
	    }
	  1
	 ' <$SRC_HOME/TakeAction >$CONFIG/bin/TakeAction

   although perhaps the best way is to add

     PATH=@PATH@ ; export PATH

   to $SRC_HOME/TakeAction and use

     sed 's;@PATH@;$CONFIG/bin:$UTIL_HOME/bin:$PATH;' \
       <$SRC_HOME/TakeAction >$CONFIG/bin/TakeAction

   in INSTALL.

Even with these fixes the install still fails because mk_config tries
to cd to $CONFIG/mach which doesn't exist; I haven't figured out that
one yet.

Re: [Tack-devel] CVS & the new build system

[tim k. <gt...@di...>]

At 7:35 PM -0400 7/24/06, David Given wrote:
>Currently it has to be on the path.
>
>What I do on the Sourceforge compile farm is to install LLgen into my home
>directory (-DPREFIX=$HOME/) and then change my PATH to include $HOME/bin
>(PATH=$PATH:$HOME/bin) before building the ACK.

This does work, and I can confirm that ACK builds on OpenBSD/macppc 3.5:

host:staging {150} bin/ack -v -O -ansi test.c -c.s -marm
cem test.c
opt test.k
be test.m
host:staging {151} arch
OpenBSD.powerpc

test.s:

.sect .text
.sect .rom
.sect .data
.sect .bss
.extern _foo
.sect .text
_foo:
STMFD R12<,{R13,R14}
MOV R13,R12
LDR R11,[R13,#8]
ADD R0,R11,#1
MOV R12,R13
LDMFD R12<,{R13,R15}


This was run from ./pm -p to clear the object cache.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] Prime Mover commands

[David G. <dg...@co...>]

tim kelly wrote:
[...]
> Is there an equivalent to 'make clean' (which I know has to be coded in=
to
> the Makefiles)?  While I really, really appreciate the incremental buil=
d
> feature to Prime Mover, sometimes I would like to start over and make s=
ure
> a build runs through from start to finish.

Add -p to the command line and it'll wipe out the intermediate file cache=

before building; alternatively, just remove /tmp/ack-temp. (There isn't a=

separate 'clean' stage.) -h will give you a list of the other command lin=
e
options.

--=20
+- David Given --McQ-+ "Gaping from its single obling socket was
|  dg...@co...    | scintillating, many fauceted scarlet emerald..."
| (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)

Re: [Tack-devel] CVS & the new build system

[David G. <dg...@co...>]

tim kelly wrote:
[...]
> Yes, and looking through the specific line in the pmfile that failed, i=
t
> was building util/cpp, which is the first utility in the process to req=
uire
> LLgen, as far as I can tell.  Looks like util/topgen is the only other
> utility that needs LLgen.  I'm still grepping through the other files.

Yeah, cgg, ncgg, ack itself, and in fact every pretty much every app that=

wants to parse text uses LLgen. ast and cjhj really like LLgen.

> So what flag needs to be added to the pmfiles to specify the location f=
or
> LLgen?  (And it is possible one might wish to run different versions of=

> LLgen, plus on some systems it is not possible without root privileges =
to
> install into /usr/local, notably OpenBSD, which has it group and world
> read-execute, but not write).

Currently it has to be on the path.

What I do on the Sourceforge compile farm is to install LLgen into my hom=
e
directory (-DPREFIX=3D$HOME/) and then change my PATH to include $HOME/bi=
n
(PATH=3D$PATH:$HOME/bin) before building the ACK.

--=20
+- David Given --McQ-+ "Gaping from its single obling socket was
|  dg...@co...    | scintillating, many fauceted scarlet emerald..."
| (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)

[Tack-devel] Prime Mover commands

[tim k. <gt...@di...>]

Hi David,
Is there an equivalent to 'make clean' (which I know has to be coded into
the Makefiles)?  While I really, really appreciate the incremental build
feature to Prime Mover, sometimes I would like to start over and make sure
a build runs through from start to finish.

thanks,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] CVS & the new build system

[tim k. <gt...@di...>]

At 6:03 PM -0400 7/24/06, tim kelly wrote:
>At 6:36 PM -0400 7/24/06, David Given wrote:
>>tim kelly wrote:
>>[...]
>>> host:Ack {114} ./pm -DPREFIX=/home/lapd/ack/bin/ configure
>>> host:Ack {115} ./pm -DPREFIX=/home/lapd/ack/bin/
>>
>>Ah --- I suspect you're confusing the LLgen installation procedure with the
>>ACK one! -DPREFIX only applies to LLgen. You have to install it so that LLgen
>>is on the path. Once that's done, './pm configure && ./pm' will build the ACK
>>(somewhere else).
>
>Ok, I was thinking the PREFIX path coded some paths.

My fault - I mis-spoke.  No, I wasn't confusing the two installation
procedures :-)  I was trying to install ACK in the same directory that I
had set up for the LLgen binary, in order to localize the installation.

This and the other part of the email (about flag specifying the location
for LLgen) perhaps does point towards re-merging LLgen into ACK and
bootstrapping it.

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] CVS & the new build system

[tim k. <gt...@di...>]

At 6:36 PM -0400 7/24/06, David Given wrote:
>tim kelly wrote:
>[...]
>> host:Ack {114} ./pm -DPREFIX=/home/lapd/ack/bin/ configure
>> host:Ack {115} ./pm -DPREFIX=/home/lapd/ack/bin/
>
>Ah --- I suspect you're confusing the LLgen installation procedure with the
>ACK one! -DPREFIX only applies to LLgen. You have to install it so that LLgen
>is on the path. Once that's done, './pm configure && ./pm' will build the ACK
>(somewhere else).

Ok, I was thinking the PREFIX path coded some paths.

>Basically, they're two separate packages that get installed separately. If you
>can't run LLgen from the command line, the ACK won't build.

Hmmm...there's a difference between running "LLgen" and
"/home/account/ack/bin/LLgen" :-)

>[...]
>> pm: object 'LLgen', defined at pmfile:39, failed to build with return code
>> 32512
>
>This error message doesn't mean that LLgen has failed to build, despite the
>phrasing; it means that a rule of type 'LLgen' has failed --- that is,
>something is trying to *use* LLgen but hasn't worked (because LLgen isn't on
>your path).

Yes, and looking through the specific line in the pmfile that failed, it
was building util/cpp, which is the first utility in the process to require
LLgen, as far as I can tell.  Looks like util/topgen is the only other
utility that needs LLgen.  I'm still grepping through the other files.

So what flag needs to be added to the pmfiles to specify the location for
LLgen?  (And it is possible one might wish to run different versions of
LLgen, plus on some systems it is not possible without root privileges to
install into /usr/local, notably OpenBSD, which has it group and world
read-execute, but not write).

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu

Re: [Tack-devel] CVS & the new build system

[David G. <dg...@co...>]

tim kelly wrote:
[...]
> host:Ack {114} ./pm -DPREFIX=3D/home/lapd/ack/bin/ configure
> host:Ack {115} ./pm -DPREFIX=3D/home/lapd/ack/bin/

Ah --- I suspect you're confusing the LLgen installation procedure with t=
he
ACK one! -DPREFIX only applies to LLgen. You have to install it so that L=
Lgen
is on the path. Once that's done, './pm configure && ./pm' will build the=
 ACK
(somewhere else).

Basically, they're two separate packages that get installed separately. I=
f you
can't run LLgen from the command line, the ACK won't build.

[...]
> pm: object 'LLgen', defined at pmfile:39, failed to build with return c=
ode
> 32512

This error message doesn't mean that LLgen has failed to build, despite t=
he
phrasing; it means that a rule of type 'LLgen' has failed --- that is,
something is trying to *use* LLgen but hasn't worked (because LLgen isn't=
 on
your path).

--=20
+- David Given --McQ-+ "Gaping from its single obling socket was
|  dg...@co...    | scintillating, many fauceted scarlet emerald..."
| (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)

Re: [Tack-devel] CVS & the new build system

[tim k. <gt...@di...>]

At 4:50 PM -0400 7/24/06, David Given wrote:
>However, the only change is to the 'pmfile' file, so you could always pull
>that out of cvsweb and patch a 1.0.2 version manually. LLgen is very static
>code; once it's installed, you'll probably never have to touch it again.

Ok, I manually added the CINCLUDES line to pmfile in both LLgen standalone
and ACK's included version.  Here is the OpenBSD error message, which is
pretty much identical to NetBSD's:

host:Ack {114} ./pm -DPREFIX=/home/lapd/ack/bin/ configure
host:Ack {115} ./pm -DPREFIX=/home/lapd/ack/bin/
rm -f "/tmp/ack-temp/pmcache/465/Lpars.h"
"/tmp/ack-temp/pmcache/465/Lpars.c" "/tmp/ack-temp/pmcache/465/tokenfile.c"
"/tmp/ack-temp/pmcache/465/expression.c"
cd /tmp/ack-temp/pmcache/465 && LLgen
"/tmp/ack-temp/pmcache/464/tokenfile.g"
"/home/account/ack/Ack/util/cpp/expression.g"
sh: LLgen: not found
rm -f "/tmp/ack-temp/pmcache/465/Lpars.h"
"/tmp/ack-temp/pmcache/465/Lpars.c" "/tmp/ack-temp/pmcache/465/tokenfile.c"
"/tmp/ack-temp/pmcache/465/expression.c"
pm: object 'LLgen', defined at pmfile:39, failed to build with return code
32512

I think the problem is a lot like what happened with the old tree, where
files weren't being found because of differences in the shells and handling
PATH stuff.  I use tcsh; it seems to me that the shell scripts are sh/bash,
but I'm not a shell expert by any means.

HTH,
tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu