This repository has been archived by the owner. It is now read-only.

build: install node and static library headers #6332

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
6 participants
@tjfontaine

fixes #5112

@TooTallNate

This comment has been minimized.

Show comment Hide comment
@TooTallNate

TooTallNate Oct 10, 2013

This should probably be opt-in with a configure flag (--install-headers, or something). This is mostly for .deb maintainers and the likes right?

This should probably be opt-in with a configure flag (--install-headers, or something). This is mostly for .deb maintainers and the likes right?

@tjfontaine

This comment has been minimized.

Show comment Hide comment
@tjfontaine

tjfontaine Oct 10, 2013

This is to restore the functionality that we used to have in v0.8 largely, it is useful for everyone, but especially helpful for platform distributors, these are tiny files and I see no reason for it to be opt in, especially since it will be most helpful moving forward for node-gyp.

This is to restore the functionality that we used to have in v0.8 largely, it is useful for everyone, but especially helpful for platform distributors, these are tiny files and I see no reason for it to be opt in, especially since it will be most helpful moving forward for node-gyp.

@trevnorris

This comment has been minimized.

Show comment Hide comment
@trevnorris

trevnorris Oct 11, 2013

It feels strange doing an #include <node/node_buffer.h>

Feel like this needs some more thinking through. Like, just include
everything user facing in node.h, or the include should be like
<node/buffer.h>

It feels strange doing an #include <node/node_buffer.h>

Feel like this needs some more thinking through. Like, just include
everything user facing in node.h, or the include should be like
<node/buffer.h>

@bnoordhuis

This comment has been minimized.

Show comment Hide comment
@bnoordhuis

bnoordhuis Oct 11, 2013

Member

You can find a more elaborate reply here but the tl;dr is "-1, do not want."

Member

bnoordhuis commented Oct 11, 2013

You can find a more elaborate reply here but the tl;dr is "-1, do not want."

@TooTallNate

This comment has been minimized.

Show comment Hide comment
@TooTallNate

TooTallNate Oct 11, 2013

I still feel link bundling the headers, gzipped, in the node executable would be way more reliable. So basically a -1 from me as well for the reasons that @bnoordhuis has been pointing out. Plus we gotta remember about Windows, which I think you guys are starting to overlook ;)

I still feel link bundling the headers, gzipped, in the node executable would be way more reliable. So basically a -1 from me as well for the reasons that @bnoordhuis has been pointing out. Plus we gotta remember about Windows, which I think you guys are starting to overlook ;)

@trevnorris

This comment has been minimized.

Show comment Hide comment
@trevnorris

trevnorris Oct 16, 2013

I'm still not for how we'd be exporting the headers. having node_<name>.h seems really clunky. Instead we should clean up internally how we export stuff. I don't get why we can't just have a single include/node.h that includes everything we deem appropriate for public consumption.

I'm still not for how we'd be exporting the headers. having node_<name>.h seems really clunky. Instead we should clean up internally how we export stuff. I don't get why we can't just have a single include/node.h that includes everything we deem appropriate for public consumption.

@tjfontaine

This comment has been minimized.

Show comment Hide comment
@tjfontaine

tjfontaine Oct 16, 2013

We can talk about changing the names in master but for backward compat
we still need to provide those names that addons are expecting

We can talk about changing the names in master but for backward compat
we still need to provide those names that addons are expecting

tools/install.py
+ files = [dirpath + '/' + f for f in filenames if f.endswith('.h')]
+ ret[dest + dirpath.replace(path, '')] = files
+ for subdir, files in ret.items():
+ action(files, subdir + '/')

This comment has been minimized.

Show comment Hide comment
@indutny

indutny Dec 13, 2013

Member

Why not move dest + there ?

@indutny

indutny Dec 13, 2013

Member

Why not move dest + there ?

@indutny

This comment has been minimized.

Show comment Hide comment
@indutny

indutny Dec 13, 2013

Member

Linux part LGTM

Member

indutny commented Dec 13, 2013

Linux part LGTM

@tjfontaine

This comment has been minimized.

Show comment Hide comment
@tjfontaine

tjfontaine Dec 18, 2013

after discussion with @isaacs this was partially landed, restoring the unix portions of this in 32478ac

the windows portions will land after I've addressed @piscisaureus's concerns

after discussion with @isaacs this was partially landed, restoring the unix portions of this in 32478ac

the windows portions will land after I've addressed @piscisaureus's concerns

@jasnell

This comment has been minimized.

Show comment Hide comment
@jasnell

jasnell Aug 13, 2015

Owner

@misterdjules @orangemocha ... any reason to keep this one open? I can't imagine any.

Owner

jasnell commented Aug 13, 2015

@misterdjules @orangemocha ... any reason to keep this one open? I can't imagine any.

@jasnell jasnell added the build label Aug 15, 2015

@jasnell

This comment has been minimized.

Show comment Hide comment
@jasnell

jasnell Aug 16, 2015

Owner

Closing this here. If there is any reason to pursue this, a new PR would need to be opened in nodejs/master once the v0.10 branch moves over.

Owner

jasnell commented Aug 16, 2015

Closing this here. If there is any reason to pursue this, a new PR would need to be opened in nodejs/master once the v0.10 branch moves over.

@jasnell jasnell closed this Aug 16, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.