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

Add a simplistic "make install" target #85

Closed
wants to merge 1 commit into from

Conversation

benley
Copy link
Contributor

@benley benley commented Dec 8, 2015

To really do this properly would probably mean setting up autoconf
and/or automake, which doesn't sound like a ton of fun. This mimics a
subset of what such a system would produce, which should make life
easier for distribution packagers.

To really do this properly would probably mean setting up autoconf
and/or automake, which doesn't sound like a ton of fun.  This mimics a
subset of what such a system would produce, which should make life
easier for distribution packagers.

This tangentally addresses google#53.
@sparkprime
Copy link
Member

Does the autoconf stuff you're working on need this or replace this?

@benley
Copy link
Contributor Author

benley commented Dec 10, 2015

It would replace this.

@benley
Copy link
Contributor Author

benley commented Dec 10, 2015

I have the autotools stuff working now, but haven't worked out how to get the tests back into it yet. Almost there.

@davidzchen
Copy link
Contributor

Just wondering, what is the motivation for choosing Autotools over CMake?

@benley
Copy link
Contributor Author

benley commented Dec 10, 2015

To be completely honest I didn't give that a lot of consideration; it's just because I've used autotools a bit in the past and it seems like the universal lowest-common-denominator build system. Personally I'd prefer to use Bazel, but having a generic ./configure;make;make install build method would be good for user adoption and distro packaging and such.

@benley
Copy link
Contributor Author

benley commented Dec 10, 2015

libtool does make the autotools build pretty slick though; it correctly builds shared libraries with pkgconfig metadata on linux, macos, and probably a bunch of other platforms without further fiddling.

@sparkprime
Copy link
Member

cmake does build visual studio files which might be useful. However last time I tried to build Jsonnet on msvc, it crashed the compiler... So probably best for people to use g++ on windows for now.

Ditto on bazel -- it's nice but I think we'll need the fallback and then we'll have to maintain both and that would be a pain.

I have fixed the integration tests btw, merge master to get that.

@sparkprime
Copy link
Member

Just remembered that we do actually have a bazel BUILD file now... :)

@benley
Copy link
Contributor Author

benley commented Dec 12, 2015

I'll get back to the autotools project in a few days, I think. Might also try doing it with cmake to see how that goes.

@sparkprime
Copy link
Member

The irony is Jsonnet is a great tool for describing builds :)

@benley
Copy link
Contributor Author

benley commented Dec 12, 2015

Heh, in that case Repobuild might be an appealing build system! (I'm not being serious, but you may find it amusing: it's like bazel, but uses JSON instead of a python-like dsl)

@davidzchen
Copy link
Contributor

From Repobuild's README:

Similar to Google's BUILD file system of old (gconfig + make)

Now that's a bit of old history. :)

Similarly, Kythe also had its own custom Campfire build system, which was also similar to BUILD but used JSON, before they fully switched to Bazel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants