Ticket #691 (closed bug: fixed)

Opened 5 years ago

Last modified 3 years ago

installed pbc_to_exe can't find config.fpmc.

Reported by: coke Owned by: Util
Priority: blocker Milestone:
Component: install Version: 1.2.0
Severity: medium Keywords: tcl blocker
Cc: Language: tcl
Patch status: Platform:

Description

1;0 coke@feather:~/sandbox/partcl$ cat foo.pir
.sub main :main
  say 'hello world'
.end
1;0 coke@feather:~/sandbox/partcl$ parrot --version
This is Parrot version 1.2.0 built for i386-linux.
Copyright (C) 2001-2009, Parrot Foundation.

This code is distributed under the terms of the Artistic License 2.0.
For more details, see the full text of the license in the LICENSE file
included in the Parrot source tree.

1;0 coke@feather:~/sandbox/partcl$ parrot foo.pir
hello world
1;0 coke@feather:~/sandbox/partcl$ pbc_to_exe foo.pir
Can't read '/usr/local/runtime/parrot/include/config.fpmc' : No such file or directory
current instr.: '_config' pc 77 (library/config.pir:88)
called from Sub 'handle_args' pc 277 (tools/dev/pbc_to_exe.pir:148)
called from Sub 'main' pc 97 (tools/dev/pbc_to_exe.pir:32)

Change History

  Changed 5 years ago by coke

  • priority changed from normal to blocker
  • version set to 1.2.0

  Changed 5 years ago by Infinoid

For reference, config.fpmc was installed with a different path. The installed path was: /usr/local/lib/parrot/1.2.0/include/config.fpmc

  Changed 5 years ago by coke

  • lang set to tcl

  Changed 5 years ago by Util

As of r39589, this test case works for me, having done sudo make install:

    echo ".sub main :main"      > foo.pir
    echo "  say 'hello world'" >> foo.pir
    echo ".end"                >> foo.pir
    parrot  -o foo.pbc foo.pir
    pbc_to_exe foo.pbc
    ./foo

Output:

hello world

  Changed 5 years ago by Util

That most-recent test was a false positive. Coke pointed out that the test is not valid unless the build dir is removed or renamed, since the core of the issue is that build paths are being used instead of installed paths.

  Changed 5 years ago by Util

  • owner set to Util
  • status changed from new to assigned

I am taking ownership of the ticket. Chromatic will also be working on the issue.

Rakudo will benefit from this issue being resolved before the 1.4 release.

From  http://irclog.perlgeek.de/parrotsketch/2009-07-07#i_1295986 :

18:49	chromatic	Other priorities?
18:49	pmichaud 	Are we likely to have the installed pbc_to_exe issues resolved before release?
18:49	chromatic	I certainly hope so.
18:49	pmichaud 	Who is working on that?
18:50	chromatic	I see some comments from Gerd.
18:50	         	Maybe Util and I can poke at it.
18:50	pmichaud 	it might "fall out" of the work I'm planning to do on an install refactor, but it might not.
18:50	Util     	I touched the ticket last. I can at least move it further along.
18:51	chromatic	Should we wait to see what you're working on for installation?
18:51	pmichaud 	Given that there's some question as to whether installation will land by next week, I think it needs to go in parallel.
18:51	         	because we really do need pbc_to_exe working, even if 'make' doesn't get refactored.
18:51	Util     	I am willing to work in parallel, and risk work being invalidated.
18:51	pmichaud 	I don't think it'll be invalidated.
18:52	         	I think it'll end up being the same for the branch.
18:52	chromatic	Alright, we'll work on it.

follow-up: ↓ 8   Changed 5 years ago by Util

Status update: Currently adding code to tools/dev/pbc_to_exe.pir, to identify whether pbc_to_exe itself is running from an installed copy, and to adjust some paths.

in reply to: ↑ 7 ; follow-up: ↓ 10   Changed 5 years ago by doughera

Replying to Util:

Status update: Currently adding code to tools/dev/pbc_to_exe.pir, to identify whether pbc_to_exe itself is running from an installed copy, and to adjust some paths.

It's not obvious to me that this is the best strategy. See TT #649 for more context and pointers to some relevant threads on the mailing list.

  Changed 5 years ago by pmichaud

  • component changed from none to install

in reply to: ↑ 8 ; follow-up: ↓ 12   Changed 5 years ago by allison

Replying to doughera:

It's true, eventually the tools shouldn't have to check whether they're running installed or from a build tree. For now we want to make sure they work installed, even though we plan to continue cleaning up the install process. A quick check whether the tool is running installed is a reasonable short-term solution.

  Changed 5 years ago by coke

Verified that with current parrot (r40039), I can again 'make tclsh' with no build dir around. (partcl)

in reply to: ↑ 10 ; follow-up: ↓ 13   Changed 5 years ago by doughera

Replying to allison:

It's true, eventually the tools shouldn't have to check whether they're running installed or from a build tree. For now we want to make sure they work installed, even though we plan to continue cleaning up the install process. A quick check whether the tool is running installed is a reasonable short-term solution.

Fair enough, though far from ideal. Since there's only 1 week to go before the next supported release, any "short-term" solutions will be the "supported" solutions for at least the next 6 months.

Replying to coke:

Verified that with current parrot (r40039), I can again 'make tclsh' with no build dir around.

That's good news, but I note that partcl currently builds only because it correctly navigates the maze of inconsistently named and used install vs. non-install variables generated by Configure.pl.

I had hoped to help folks clean up the underlying mess rather than spending time continuing to patch around it, but there is no more time. As of the 1.4 release, that mess is going to be the supported scheme.

in reply to: ↑ 12   Changed 5 years ago by allison

Replying to doughera:

Fair enough, though far from ideal. Since there's only 1 week to go before the next supported release, any "short-term" solutions will be the "supported" solutions for at least the next 6 months.

What's "supported" is that pbc_to_exe will be able to create executables from bytecode, and will continue to accept the same command-line options. We're completely free to change the internal implementation of pbc_to_exe, refactor the code, or even rewrite it from scratch.

The idea of supported releases is not to be draconian about "backward compatibility", but to give users adequate notice of changes (improvements) that will affect the way they interact with the code.

  Changed 4 years ago by jkeenan

Util,

Doing cage-cleaning tonight, it appears to me that (a) the issue Coke raised in the OP have been resolved; (b) subsequent posts are part of the (seemingly interminable) debate over deprecation policies and should be discussed elsewhere.

So, is this ticket closeable?

Thank you very much.

kid51

  Changed 3 years ago by bacek

Hello.

+1 for close this ticket.

-- Bacek

  Changed 3 years ago by cotto

  • status changed from assigned to closed
  • resolution set to fixed

I've verified that a current installed pbc_to_exe can correctly find config.fpmc by installing, nuking the build dir and running the installed pbc_to_exe on a pbc file. After installing normally, pbc_to_exe works. If I delete the installed config.fpmc, it fails. I'm marking this ticket resolved. Thanks to kid51 and bacek for noticing that this is fixed.

Note: See TracTickets for help on using tickets.