Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure script parameters not honored -- /usr/local "prefix" used regardless for "run" directory #219

Closed
Corin-EU opened this issue Sep 3, 2022 · 4 comments
Assignees
Labels
bug Something isn't working priority-low
Milestone

Comments

@Corin-EU
Copy link

Corin-EU commented Sep 3, 2022

This relates to the latest papl r.1446335

As is standard for the GNU autotools "configure" script, parameters are provided to set paths, eg

        --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
       --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
       --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
       --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]

as well as others so that the prefix (default /usr/local)

However the paths for the state and run directories are hardcoded in config.h.in and config.h

           // Location of PAPPL state and spool data (when run as root)
          #define PAPPL_STATEDIR "/usr/local/var"

          // Location of PAPPL domain socket (when run as root)
         #define PAPPL_SOCKDIR "/usr/local/var/run"

It would be helpful if this code was modified to use those values as backups if the symbolic constants are not defined by the Makefile invocation which gets the specified value via localstatedir and runstatedir parameters when the Makefile is created by the configure script.

However as a test I deleted the Makefile, ran configure but no Makefile was created as is normally expected for the execution of configure.

Also, I edited the config.h.in file which I thought was being used to create the config.h and after editing it to change the STATEDIR and SOCKDIR paths, and then running confgure found that it had made no difference, so it appears that those lines in config.h.in are being iignored and configure is just stuffing the prefix value + var [+ run] into config.h regardless of the localstatedir and runstatedir being specified.

Although /usr/local/var and /usr/local/var/run are consistent with the default prefix /usr/local, I would suggest that for practical use, the defaults should be the system /var and system /run (/var/run is now almost always a symbolic link to /run, a transitory tmpfs directory)

@Corin-EU
Copy link
Author

Corin-EU commented Sep 3, 2022

Upon further investigation, I made a mistake above about the behavior of configure.

For this project there is a fixed Makefile which pulls in the variables from Makedefs.

When I run configure with

       configure --prefix=/usr/local  --localstatedir=/var  --sharedstatedir=/run

the Makedefs file is generated with localstatedir and sharestedir withthe correct values of "/var" and "/run" but the problem remains that the generated "config.h" does not contain these values but the default values of "/usr/local/var" and "/usr/local/var/run" so the problem is at the level of the generation of the config.h

@michaelrsweet
Copy link
Owner

@Corin-EU I will update the defaults for this to use the localstatedir value (sharedstatedir never gets used), but I explicitly made these separate configure options (--with-papplstatedir and --with-papplsockdir) since these are the directories other applications will end up using and not necessarily where PAPPL gets installed...

@michaelrsweet michaelrsweet self-assigned this Sep 5, 2022
@michaelrsweet michaelrsweet added bug Something isn't working priority-low labels Sep 5, 2022
@michaelrsweet michaelrsweet added this to the v1.3 milestone Sep 5, 2022
michaelrsweet added a commit that referenced this issue Sep 5, 2022
@michaelrsweet
Copy link
Owner

[master 15bd0cd] Fix default values of PAPPL_SOCKDIR and PAPPL_STATEDIR, also update CUPS_SERVERROOT on macOS (Issue #219)

@Corin-EU
Copy link
Author

Thank you for the fix.

michaelrsweet added a commit that referenced this issue Sep 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority-low
Projects
None yet
Development

No branches or pull requests

2 participants