Discussion:
[Emc-developers] problems running source build of 2.8 master
Jon Elson
2017-03-05 19:47:06 UTC
Permalink
Hello, all,

I'm working on the fix to the hal_ppmc driver discussed last
weekend. So, first is to install a developer clone of the
master 2.8.0~pre1 version. I did this, and found that some
things that worked before are broken.

First item is a loadrt command line option.

The command line (in univpwm_load.hal) is this :

loadrt hal_ppmc port_addr="0xecf8" timestamp="0x00"

And, I get this error :

Found file(REL): ./univpwm_load.hal
Note: Using POSIX realtime
timestamp=0x00: Invalid type character `*'
./univpwm_load.hal:13: waitpid failed
/home/elson/linuxcnc-2.8/bin/rtapi_app hal_ppmc
./univpwm_load.hal:13:
/home/elson/linuxcnc-2.8/bin/rtapi_app exited without
becoming ready
./univpwm_load.hal:13: insmod for hal_ppmc failed, returned -1
Shutting down and cleaning up LinuxCNC...
Note: Using POSIX realtime
LinuxCNC terminated with an error. You can find more
information in the log:
/home/elson/linuxcnc_debug.txt
and
/home/elson/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in
the terminal

_______________________________

If I remove the timestamp="0x00" parameter from the command
line, the driver loads, and if I remove the hal code that
uses the pins exported by that option, then most of the
config seems to work. There is no asterisk character in the
command line, as the error line seems to suggest. The port
address parameter is working properly.

Anybody have any idea what is causing this error?

The other thing I observed is that the jog pendant does not
work, but keyboard jogging does work. I haven't done any
digging into why that might be.

Thanks,

Jon
Jon Elson
2017-03-05 20:09:20 UTC
Permalink
Post by Jon Elson
loadrt hal_ppmc port_addr="0xecf8" timestamp="0x00"
timestamp=0x00: Invalid type character `*'
OK, I've been doing some more testing. The same error
occurs when I specify
timestamp=0

and when I specify the 0x378 parallel port.

Is there someplace else that needs to know about the command
line parameters of rt modules?

I added two parameters to the line a few years ago,
timestamp and enc_clock, did some code in the loadrt command
lose those?

Thanks,

Jon
Jon Elson
2017-03-05 21:37:58 UTC
Permalink
On 03/05/2017 02:09 PM, Jon Elson wrote:

Ah, a quirk in the 2.8 hal file updater.

It changed axis.0.jog-scale and axis.0.jog-counts to
joint.0... properly, but missed
axis.0.jog-enable

When I fixed that manually, jogging worked.

Jon
andy pugh
2017-03-06 01:05:11 UTC
Permalink
Post by Jon Elson
Ah, a quirk in the 2.8 hal file updater.
Can you raise a detailed bug report, with what line was changed
erroneously to what?

I recently fixed a jog-translation bug and might have introduced a new
one with the fix.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Jon Elson
2017-03-06 01:14:38 UTC
Permalink
Post by andy pugh
Post by Jon Elson
Ah, a quirk in the 2.8 hal file updater.
Can you raise a detailed bug report, with what line was changed
erroneously to what?
I recently fixed a jog-translation bug and might have introduced a new
one with the fix.
Not erroneous change, just a failure to change a line that
needed to be changed from
axis.0.jog-enable to joint.0.jog-enable

Jon
andy pugh
2017-03-06 01:32:03 UTC
Permalink
Post by Jon Elson
Not erroneous change, just a failure to change a line that
needed to be changed from
axis.0.jog-enable to joint.0.jog-enable
The regex list has:

'axis.(.).jog-enable': '@ax\\***@.jog-enable',

'axis.(.).jog-counts': 'joint.\\1.jog-counts @ax\\***@.jog-counts',

'axis.(.).jog-scale': 'joint.\\1.jog-scale @ax\\***@.jog-scale',

'axis.(.).jog-vel-mode': 'joint.\\1.jog-vel-mode @ax\\***@.jog-vel-mode',

So you are right, it explicitly doubles-up the axis enables, to cover
both joint and axis, but simply converts the axis.N.jog enable to
axis.L.jog-enable.
I do rather assume I thought there was a good reason for this, at the
time, so I am not going to change it immediately without further
consideration.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Jon Elson
2017-03-06 01:47:50 UTC
Permalink
Post by andy pugh
Post by Jon Elson
Not erroneous change, just a failure to change a line that
needed to be changed from
axis.0.jog-enable to joint.0.jog-enable
So you are right, it explicitly doubles-up the axis enables, to cover
both joint and axis, but simply converts the axis.N.jog enable to
axis.L.jog-enable.
I do rather assume I thought there was a good reason for this, at the
time, so I am not going to change it immediately without further
consideration.
Right, not a big problem at all. I kind of wonder how come
there are axis.n.jog-xxxx and joint.x.jog-xxxx, but maybe
that is for world AND joint mode (a case I am totally out of
the loop with, working exclusively on cartesian machines.)

Jon
Dewey Garrett
2017-03-06 02:29:58 UTC
Permalink
I kind of wonder how come there are axis.n.jog- and
joint.x.jog-
The master branch has many changes with incorporation
of more complete joints/axes distinctions. Developers
attempt to document:

http://linuxcnc.org/docs/devel/html/getting-started/updating-linuxcnc.html

For example, hal pin changes for wheel jogging are described:

http://linuxcnc.org/docs/devel/html/getting-started/updating-linuxcnc.html#_whee
l_or_mpg_manual_pulse_generator_jogging
--
Dewey Garrett
Nicklas Karlsson
2017-03-05 20:10:53 UTC
Permalink
No idea but I have used 2.8 master for quite a long time but is probably a few months since last time I updated.

On Sun, 05 Mar 2017 13:47:06 -0600
Post by Jon Elson
Hello, all,
I'm working on the fix to the hal_ppmc driver discussed last
weekend. So, first is to install a developer clone of the
master 2.8.0~pre1 version. I did this, and found that some
things that worked before are broken.
First item is a loadrt command line option.
loadrt hal_ppmc port_addr="0xecf8" timestamp="0x00"
Found file(REL): ./univpwm_load.hal
Note: Using POSIX realtime
timestamp=0x00: Invalid type character `*'
./univpwm_load.hal:13: waitpid failed
/home/elson/linuxcnc-2.8/bin/rtapi_app hal_ppmc
/home/elson/linuxcnc-2.8/bin/rtapi_app exited without
becoming ready
./univpwm_load.hal:13: insmod for hal_ppmc failed, returned -1
Shutting down and cleaning up LinuxCNC...
Note: Using POSIX realtime
LinuxCNC terminated with an error. You can find more
/home/elson/linuxcnc_debug.txt
and
/home/elson/linuxcnc_print.txt
as well as in the output of the shell command 'dmesg' and in
the terminal
_______________________________
If I remove the timestamp="0x00" parameter from the command
line, the driver loads, and if I remove the hal code that
uses the pins exported by that option, then most of the
config seems to work. There is no asterisk character in the
command line, as the error line seems to suggest. The port
address parameter is working properly.
Anybody have any idea what is causing this error?
The other thing I observed is that the jog pendant does not
work, but keyboard jogging does work. I haven't done any
digging into why that might be.
Thanks,
Jon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Jon Elson
2017-03-05 20:26:34 UTC
Permalink
Post by Nicklas Karlsson
No idea but I have used 2.8 master for quite a long time but is probably a few months since last time I updated.
Something got broken, but I have no idea what, right now. I
have a loadrt command with two parameters.
One parameter works just like always, the other one gets a
rather strange error message complaining about a
`*' in the command line, but there is no such character there.

Jon
Jon Elson
2017-03-05 22:32:29 UTC
Permalink
OK, to restate the problem, the hal_ppmc.c driver has 5
optional parameters, created with the
RTAPI_MP_ARRAY_INT function. The first one works, all the
rest get a strange error message
if you try to invoke them in the loadrt command line.

Now, the 4 later parameters are a bit odd, they allow you to
supply a list of values.
The code looks like this :
int timestamp[MAX_BUS*8] = {
-1,-1,-1,-1,-1,-1,-1,-1,
-1,-1,-1,-1,-1,-1,-1,-1,
-1,-1,-1,-1,-1,-1,-1,-1 }; /* default, no extra
stuff */
RTAPI_MP_ARRAY_INT(timestamp, MAX_BUS*8, "bus/slot locations
of timestamped encoders");

Can anybody see anything wrong with the way these are coded
up? If one of these parameters is supplied, the error
is :
timestamp=0x00: Invalid type character `*'

Which doesn't make much sense to me.

If you omit the troublesome parameter, then the driver seems
to work fine.

Thanks,

Jon
Jon Elson
2017-03-05 20:24:11 UTC
Permalink
Post by Jon Elson
First item is a loadrt command line option.
loadrt hal_ppmc port_addr="0xecf8" timestamp="0x00"
Oh, some other details. This is happening on a uspace build
from source. Anyone should be able to run the
configs/by_interface/pico/univpwmv sample config and
demonstrate the error, without any hardware attached.
If the timestamp parameter is removed, you would get it
scanning the epp port for devices and then quitting if it
didn't find any.

I was hoping to get this fix tested today and get it
committed, but I'm totally stumped by this situation.

Thanks,

Jon
Jeff Epler
2017-03-06 05:54:03 UTC
Permalink
Post by Jon Elson
timestamp=0x00: Invalid type character `*'
The related line in the source is:
src/hal/drivers/hal_ppmc.c:RTAPI_MP_ARRAY_INT(timestamp, MAX_BUS*8, "bus/slot locations of timestamped encoders");
due to a technical limitation, the second parameter to
RTAPI_MP_ARRAY_INT must be a literal number, not the result of a
calculation. This limitation is only present for "uspace" builds of
LinuxCNC, and is unfortunately not diagnosed at compile time, but rather
only when the parameter is used. Since MAX_BUS is 3, the fix is to
replace this instance of MAX_BUS*8 with the literal number 24, or do the
harder work of removing this limitation of RTAPI_MP_ARRAY macros on
uspace builds.

Jeff
andy pugh
2017-03-06 10:35:17 UTC
Permalink
Post by Jeff Epler
Since MAX_BUS is 3, the fix is to
replace this instance of MAX_BUS*8 with the literal number 24
Or #define MAX_BUS*8 24 ?
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
Jeff Epler
2017-03-06 14:14:24 UTC
Permalink
Post by Jeff Epler
src/hal/drivers/hal_ppmc.c:RTAPI_MP_ARRAY_INT(timestamp, MAX_BUS*8, "bus/slot locations of timestamped encoders");
due to a technical limitation, the second parameter to
RTAPI_MP_ARRAY_INT must be a literal number, not the result of a
[...]

This turns out to be easier to fix than I worried it would be.
https://github.com/LinuxCNC/linuxcnc/pull/243
Jon Elson
2017-03-06 18:32:49 UTC
Permalink
Post by Jeff Epler
Post by Jon Elson
timestamp=0x00: Invalid type character `*'
src/hal/drivers/hal_ppmc.c:RTAPI_MP_ARRAY_INT(timestamp, MAX_BUS*8, "bus/slot locations of timestamped encoders");
due to a technical limitation, the second parameter to
RTAPI_MP_ARRAY_INT must be a literal number, not the result of a
calculation. This limitation is only present for "uspace" builds of
LinuxCNC, and is unfortunately not diagnosed at compile time, but rather
only when the parameter is used. Since MAX_BUS is 3, the fix is to
replace this instance of MAX_BUS*8 with the literal number 24, or do the
harder work of removing this limitation of RTAPI_MP_ARRAY macros on
uspace builds.
WOW, thanks, Jeff, I would have NEVER figured this out
myself. Curiously, it works on a uspace 2.7 system!
Post by Jeff Epler
This turns out to be easier to fix than I worried it would be.
So, if I do a pull, now, it will contain the fix? I don't
see a commit, yet.

Maybe, on the other hand, one could do this :
#define MAX_BUS 3
#define MAX_CARDS MAX_BUS*8

RTAPI_MP_ARRAY_INT(timestamp, MAX_CARDS, "bus/slot locations of timestamped encoders");




Thanks so much, this one was a bit beyond my level.

Jon
Jon Elson
2017-03-07 02:33:56 UTC
Permalink
Post by Jon Elson
WOW, thanks, Jeff, I would have NEVER figured this out
myself. Curiously, it works on a uspace 2.7 system!
Great, it works! Thanks for the quick fix!

Jon
Jeff Epler
2017-03-07 04:48:31 UTC
Permalink
Post by Jon Elson
Great, it works! Thanks for the quick fix!
Thanks for verifying the fix.

Jeff
Jon Elson
2017-03-11 03:46:08 UTC
Permalink
Post by Jeff Epler
Post by Jon Elson
Great, it works! Thanks for the quick fix!
Thanks for verifying the fix.
OK, now that I've verified that my fix to hal_ppmc fixes the
original problem with PCIe parport cards, I wonder if we
should backport that to 2.7? It is this commit :

a36f3aa41b21098645c84631055db73136c77515

Which seems to only have been merged to master at this time.

I could do it if somebody gives me EXACT instructions, but
I'm a real novice at git.

Jon
Sebastian Kuzminsky
2017-03-11 17:50:57 UTC
Permalink
Post by Jon Elson
Post by Jeff Epler
Post by Jon Elson
Great, it works! Thanks for the quick fix!
Thanks for verifying the fix.
OK, now that I've verified that my fix to hal_ppmc fixes the
original problem with PCIe parport cards, I wonder if we
a36f3aa41b21098645c84631055db73136c77515
Which seems to only have been merged to master at this time.
I could do it if somebody gives me EXACT instructions, but
I'm a real novice at git.
Here's how I would do it:

# go into your linuxcnc git directory
Post by Jon Elson
cd linuxcnc-dev
# fetch all updates from git.linuxcnc.org
Post by Jon Elson
git fetch origin
# check out the 2.7 branch that you want add the commit to
Post by Jon Elson
git checkout 2.7
# move your 2.7 branch forward to the current state of 2.7 from glo
Post by Jon Elson
git merge --ff-only origin
git cherry-pick a36f3aa41b21098645c84631055db73136c77515
That cherry-pick command can go two ways. Either it will succeed and
commit the changes from a36f3aa4 to your 2.7 and everything is fine, or
it can have a merge conflict and stop with the changes half-applied.

*If* it has a merge conflict you'll have to resolve the situation by
hand. Use `git status` to see what files had conflicts, and edit them
to fix all the problems. Use `git add file.c` to mark them as resolved
when you're done. Build and test if you're feeling like a responsible
adult. Then `git commit` to finalize the result.

Then, once the cherry-picking is all done, push your updated 2.7 branch
Post by Jon Elson
git push origin 2.7
--
Sebastian Kuzminsky
Jon Elson
2017-03-12 02:01:28 UTC
Permalink
Post by Sebastian Kuzminsky
Post by Jon Elson
Post by Jeff Epler
Post by Jon Elson
Great, it works! Thanks for the quick fix!
Thanks for verifying the fix.
OK, now that I've verified that my fix to hal_ppmc fixes the
original problem with PCIe parport cards, I wonder if we
a36f3aa41b21098645c84631055db73136c77515
Which seems to only have been merged to master at this time.
I could do it if somebody gives me EXACT instructions, but
I'm a real novice at git.
# go into your linuxcnc git directory
Post by Jon Elson
cd linuxcnc-dev
# fetch all updates from git.linuxcnc.org
Post by Jon Elson
git fetch origin
# check out the 2.7 branch that you want add the commit to
Post by Jon Elson
git checkout 2.7
# move your 2.7 branch forward to the current state of 2.7 from glo
Post by Jon Elson
git merge --ff-only origin
git cherry-pick a36f3aa41b21098645c84631055db73136c77515
Thanks for the detailed instructions! I got all the way to
the cherry-pick command, and then got this:
***@jeuspace:~/linuxcnc-dev$ git cherry-pick
a36f3aa41b21098645c84631055db73136c77515
# On branch 2.7
# Your branch is ahead of 'origin/2.7' by 1380 commits.
#
nothing to commit (working directory clean)
The previous cherry-pick is now empty, possibly due to
conflict resolution.
If you wish to commit it anyway, use:

git commit --allow-empty

Otherwise, please use 'git reset'

_____________________

Not too sure what went wrong, can you suggest what to do to
fix it? hal_ppmc.c should be only slightly different on 2.7
and 2.8, besides my recent patch, there have been no changes
since 2013, and Jeff already merged his change to the hal
command line function.

Thanks very much,

Jon
Sebastian Kuzminsky
2017-03-12 03:45:42 UTC
Permalink
Post by Jon Elson
Post by Sebastian Kuzminsky
Post by Jon Elson
Post by Jeff Epler
Post by Jon Elson
Great, it works! Thanks for the quick fix!
Thanks for verifying the fix.
OK, now that I've verified that my fix to hal_ppmc fixes the
original problem with PCIe parport cards, I wonder if we
a36f3aa41b21098645c84631055db73136c77515
Which seems to only have been merged to master at this time.
I could do it if somebody gives me EXACT instructions, but
I'm a real novice at git.
# go into your linuxcnc git directory
Post by Jon Elson
cd linuxcnc-dev
# fetch all updates from git.linuxcnc.org
Post by Jon Elson
git fetch origin
# check out the 2.7 branch that you want add the commit to
Post by Jon Elson
git checkout 2.7
# move your 2.7 branch forward to the current state of 2.7 from glo
Post by Jon Elson
git merge --ff-only origin
git cherry-pick a36f3aa41b21098645c84631055db73136c77515
Thanks for the detailed instructions! I got all the way to
a36f3aa41b21098645c84631055db73136c77515
# On branch 2.7
# Your branch is ahead of 'origin/2.7' by 1380 commits.
Well that's not right. You should probably reset your 2.7 branch to
Post by Jon Elson
git checkout 2.7
git reset --hard origin/2.7
Then do the cherry pick as above.
--
Sebastian Kuzminsky
Jon Elson
2017-03-12 05:27:56 UTC
Permalink
On 03/11/2017 09:45 PM, Sebastian Kuzminsky wrote:

Thanks much, Seb! It says it did it this time.

Jon
Jon Elson
2017-03-14 03:51:17 UTC
Permalink
On 03/11/2017 09:45 PM, Sebastian Kuzminsky wrote:

I have now updated the 2.7 docs to include the new command
line parameter of hal_ppmc.
Can you merge that 2.8? (Doing the cherry pick of the
driver to 2.7, I managed to do something unknown to my local
2.8 repo, and will have to reload it to be sure it isn't
fouled up. I gave one or more of the cherry pick commands
in the 2.8 repo by mistake.)

This is the commit :
http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9164253


By the way, what do I need to do when building LinuxCNC to
be able to build the docs?
I got :
../docs/src/Submakefile:605: *** Cannot build documents,
missing AsciiDoc or some other required program, or
explicitly disabled in configure. Stop.

asciidoc IS installed. I did have to disable something in
the configure step to get configure to complete - it told
me to use:

--enable-non-distributable=yes

Thanks,

Jon
Sebastian Kuzminsky
2017-03-14 05:24:10 UTC
Permalink
Post by Jon Elson
I have now updated the 2.7 docs to include the new command
line parameter of hal_ppmc.
Can you merge that 2.8? (Doing the cherry pick of the
driver to 2.7, I managed to do something unknown to my local
2.8 repo, and will have to reload it to be sure it isn't
fouled up. I gave one or more of the cherry pick commands
in the 2.8 repo by mistake.)
Your push to 2.7 looks good, so i merged it to master.
Post by Jon Elson
By the way, what do I need to do when building LinuxCNC to
be able to build the docs?
../docs/src/Submakefile:605: *** Cannot build documents,
missing AsciiDoc or some other required program, or
explicitly disabled in configure. Stop.
asciidoc IS installed. I did have to disable something in
the configure step to get configure to complete - it told
--enable-non-distributable=yes
The non-distributable option should not affect the docs.

It sounds like you have asciidoc, but either you didn't enable the
building of documentation when running src/configure, or you're missing
"some other required program".

Here's a brief mention of the src/configure argument for enabling
building of documentation:

http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html#_building_for_run_in_place


And here's the docs on satisfying build dependencies:

http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html#Satisfying-Build-Dependencies


Let me know if those don't fix the problem.
--
Sebastian Kuzminsky
Jon Elson
2017-03-14 15:45:42 UTC
Permalink
Post by Sebastian Kuzminsky
Post by Jon Elson
I have now updated the 2.7 docs to include the new command
line parameter of hal_ppmc.
Can you merge that 2.8? (Doing the cherry pick of the
driver to 2.7, I managed to do something unknown to my local
2.8 repo, and will have to reload it to be sure it isn't
fouled up. I gave one or more of the cherry pick commands
in the 2.8 repo by mistake.)
Your push to 2.7 looks good, so i merged it to master.
Thanks, I already checked the buildbot document to make sure
it didn't mess up the formatting.
I really ought to rewrite the whole ppmc section, but I'm
not an English major.

Jon
Jon Elson
2017-03-17 16:04:20 UTC
Permalink
On 03/14/2017 10:45 AM, Jon Elson wrote:
It occurs to me to belatedly ask, is there going to be
another formal release of 2.7? Will this be 2.7.9?

I made an update to the ppmc driver, and merged it to 2.7.8,
but I assume that it would only appear in the buildbot
version, NOT the 2.7.8 download. Is that correct?

Thanks,

Jon
Sebastian Kuzminsky
2017-03-17 16:24:24 UTC
Permalink
Post by Jon Elson
It occurs to me to belatedly ask, is there going to be
another formal release of 2.7? Will this be 2.7.9?
Yes, i'm planning to make a 2.7.9 release soonish, and to keep making
2.7 releases after that, hopefully until 2.8.0 or 3.0 or whatever we
call it is released and mature.
Post by Jon Elson
I made an update to the ppmc driver, and merged it to 2.7.8,
but I assume that it would only appear in the buildbot
version, NOT the 2.7.8 download. Is that correct?
Yes, that's right. Released versions do not change.

New incoming changes are included in the interim builds from the
buildbot, and in all releases made after the change was made.
--
Sebastian Kuzminsky
Jon Elson
2017-03-18 02:04:56 UTC
Permalink
Post by Sebastian Kuzminsky
Post by Jon Elson
It occurs to me to belatedly ask, is there going to be
another formal release of 2.7? Will this be 2.7.9?
Yes, i'm planning to make a 2.7.9 release soonish, and to keep making
2.7 releases after that, hopefully until 2.8.0 or 3.0 or whatever we
call it is released and mature.
OK, excellent! I probably need to revise my documentation
to give the right version numbers.

Thanks,

Jon

John Thornton
2017-03-14 13:23:43 UTC
Permalink
When you run configure enable the docs to be built with one of the
following, the first one builds both pdf and html

./configure --enable-build-documentation
./configure --enable-build-documentation=pdf
./configure --enable-build-documentation=html

JT
Post by Jon Elson
I have now updated the 2.7 docs to include the new command
line parameter of hal_ppmc.
Can you merge that 2.8? (Doing the cherry pick of the
driver to 2.7, I managed to do something unknown to my local
2.8 repo, and will have to reload it to be sure it isn't
fouled up. I gave one or more of the cherry pick commands
in the 2.8 repo by mistake.)
http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9164253
By the way, what do I need to do when building LinuxCNC to
be able to build the docs?
../docs/src/Submakefile:605: *** Cannot build documents,
missing AsciiDoc or some other required program, or
explicitly disabled in configure. Stop.
asciidoc IS installed. I did have to disable something in
the configure step to get configure to complete - it told
--enable-non-distributable=yes
Thanks,
Jon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Jon Elson
2017-03-14 15:44:22 UTC
Permalink
Post by John Thornton
When you run configure enable the docs to be built with one of the
following, the first one builds both pdf and html
./configure --enable-build-documentation
./configure --enable-build-documentation=pdf
./configure --enable-build-documentation=html
THANKS!! I used to know this.

Jon
Loading...