search

sharplispers / clx

a fork of crhodes' fork of danb's fork of the CLX library, an X11 client for Common Lisp
Other
114 stars 46 forks source link

Add more symbols to package exports #131

Closed rtoy closed 5 years ago

rtoy commented 5 years ago

When compiling with cmucl, cmucl complains that these symbols are exported but not in the package. I didn't check every symbol but they all seem to be from the extensions.

rtoy commented 5 years ago

I can format this any way you want, but to make the diff simple, I just stuck all the new symbols at the end, one per line.

If you want them arranged alphabetically, I can do that. Or maybe you can have two :export lists, one of which is for the symbols from the extensions.

PuercoPop commented 5 years ago

Most of the these symbols are exported by extensions – like randr. It makes little sense to export them if the extension is not loaded. But it is cumbersome when re-evaluating the defpackage form that it signals a warning. Maybe extensions should define their own packages?

rtoy commented 5 years ago

Aren't the extensions always loaded? The asdf file always builds them.

And if the extensions define their own packages, you'll break any existing code that uses the extensions. That seems like not the right thing to do now. I think it's been this way for a very long time.

dkochmanski commented 5 years ago

They are always loaded when asdf system is loaded, but they are not part of the core clx implementation so they do not belong to package.lisp. Why does CMUCL complain though? Purpose of the function export is exactly that: add symbols to a package. If they were always defined there then there wouldn't be any need for export. I agree that moving extensions to separate packages will break too much and that is not a solution. OTOH I don't think we should "fix" things as they are now.

rtoy commented 5 years ago

I think cmucl has always printed a warning that if you have exported symbols that aren't defined in the package. It doesn't break anything if you ignore the warning; the symbols are still external.

Note that I'm not building this with asdf. I'm taking the code (pretty much as is) into cmucl and building it in the way that cmucl has always built clx. I don't get any warnings when building sharplispers/clx using asdf.

No problem if you want to reject this merge.

PuercoPop commented 5 years ago

Its not just CMUCL, SBCL will also complain when re-evaluating the package form is there are any additional symbols exported. Which is only a problem when modifying the defpackage form after the system has already been loaded once.

dkochmanski commented 5 years ago

I'll close it then. Thank you for understanding.