|
maven hatred boils down to 2 groups: 1) Im too loving stupid to understand xml 2) Im too loving stupid to understand software development everyone in group 1 is also in group 2
|
#
?
Dec 21, 2019 22:39
|
|
|
|
| # ? Apr 28, 2024 05:14 |
|
|
If there are never emergent needs then why does Maven even provide a plugin api and why have plugins been created for it, huh genius
|
|
#
?
Dec 21, 2019 22:39
|
|
|
Shaggar posted:lol this guy is dumb as gently caress don’t self introduce your posts
|
|
#
?
Dec 21, 2019 23:39
|
|
|
I like cargo itself but crates.io is very bad - any docs you include in your crates should just be a stub linking to your main docs site because even the readme for a given release can’t be changed after it’s published - binding package ownership to individual github logins is bullshit - after you claim a package name it’s yours forever so there’s already a bunch of name squatting
|
|
#
?
Dec 21, 2019 23:46
|
|
|
Gazpacho posted:gradle provides modules that can be configured similar to maven using far more efficient and readable syntax (lol @ hand-edited xml) I’m gonna ignore the hand wringing over xml because honestly who cares during my entire time developing java I have never had a case where we had emergent build system needs that we needed to iterate on because mavens extremely generic clean -> compile -> test -> package -> deploy flow covered it. the build system should be a very boring implementation detail, I want to spend next to no time thinking about it. the only time I’ve really seen people want to break out of the maven way of doing things is when they want to produce more than 1 artifact per project, and maven forcing them to use multiple projects instead usually results in a better design
|
|
#
?
Dec 22, 2019 00:20
|
|
|
maven: complete garbage ant: still garbage, but at least you can read it to see what it's doing
|
|
#
?
Dec 22, 2019 00:20
|
|
|
Shaggar posted:maven hatred boils down to 2 groups: 1) i understand xml. it sucks rear end 2) i understand software development. it also sucks rear end
|
|
#
?
Dec 22, 2019 01:41
|
|
|
i have never seen any other build tool that demanded more developer attention and babysitting than maven. even the build system developed for windows NT (a boatload of cmd scripts driven by nmake) managed to be more intuitive
|
|
#
?
Dec 22, 2019 02:07
|
|
|
akadajet posted:1) i understand xml. it sucks rear end on the other hand, i understand rear end, which i understand to be very good (and very edible)
|
|
#
?
Dec 22, 2019 03:01
|
|
|
you could try bazel it's got a proper declarative build structure, like maven but your build files look like a bunch of random python calls, so it should appeal to p-langers
|
|
#
?
Dec 22, 2019 03:54
|
|
|
Shaggar posted:maven hatred boils down to 2 groups: shaggar was right Gazpacho posted:i have never seen any other build tool that demanded more developer attention and babysitting than maven. even the build system developed for windows NT (a boatload of cmd scripts driven by nmake) managed to be more intuitive you are an embarrassment to your profession
|
|
#
?
Dec 22, 2019 04:55
|
|
|
rotor posted:convention over configuration can suck my rear end
|
|
#
?
Dec 22, 2019 05:11
|
|
|
Jenkins worked for me but I was more interested in the cd part of ci/cd at that stage
|
|
#
?
Dec 22, 2019 06:34
|
|
|
the core of jenkins sends RPCs by serializing a java object containing the code to be executed, then sending it to the worker node the worker node then deserializes and executes the object i call it RPC by RCE this is also why java versions must exactly align across all the jenkins machines
|
|
#
?
Dec 22, 2019 08:59
|
|
|
Progressive JPEG posted:the core of jenkins sends RPCs by serializing a java object containing the code to be executed, then sending it to the worker node lmao
|
|
#
?
Dec 22, 2019 09:48
|
|
|
groovy pipelines take it a step further and serialize the interpreter itself and send that to the target machine
|
|
#
?
Dec 22, 2019 22:22
|
|
|
teamcity is nice 
|
|
#
?
Dec 29, 2019 06:30
|
|
|
lmao if you have to build code
|
|
#
?
Dec 29, 2019 20:32
|
|
|
we use cake or something
|
|
#
?
Dec 29, 2019 23:21
|
|
|
and a pile of powers hell. I don't understand any of it but it seems to work without issues
|
|
#
?
Dec 29, 2019 23:21
|
|
|
some of our stuff more or less depends on eclipse to build. lmao.
|
|
#
?
Dec 30, 2019 04:36
|
|
|
Captain Foo posted:lmao if you have to build code lmao if you dont
|
|
#
?
Dec 30, 2019 04:43
|
|
|
compilers are good imo
|
|
#
?
Dec 30, 2019 21:55
|
|
|
rotor posted:The thing where people rely on this host of third-party, off-prem services (github, npm, travis, etc) to simply build and deploy their own software is insane to me. a-fuckin-men
|
|
#
?
Jan 8, 2020 09:00
|
|
|
Poopernickel posted:Use CMake, autotools, or whatever - they're all good too. this is patently false CMake is like the smelly ugly guy who chews with his mouth open and just appears fractally terrible in the small details but when the chips are down he can deliver and reliably autotools is kinda like that except it barely works and also likes to talk about open relationships and/or open carry and wants you to know that you should really make sure all your code can be built on obscure old systems that only someone like me would care about since portability is important
|
|
#
?
Jan 8, 2020 09:05
|
|
|
Brazil is good af
|
|
#
?
Jan 8, 2020 09:20
|
|
|
Feisty-Cadaver posted:we do almost everything with declarative jenkins pipeline builds + docker and it's not exactly simple to setup, but it's nice. like thousands of devs on dozens of teams with wildly different needs and all builds go through the same infra. java, c++, python, iOS, android, jabbascript, etc. spits out an artifact and i set this up but the jenkins docker kept running out of space and I got bored with being the CI guy so we're going to use travis
|
|
#
?
Jan 8, 2020 09:42
|
|
|
eschaton posted:this is patently false I looked this up for the first time in my life and wow gross https://thoughtbot.com/blog/the-magic-behind-configure-make-make-install
|
|
#
?
Jan 8, 2020 09:48
|
|
|
I use travis for the stuff i do that matters and it works fine. haven t had any complaint's yet
|
|
#
?
Jan 8, 2020 11:41
|
|
|
my stepdads beer posted:I looked this up for the first time in my life and wow gross yep, it's ugly for sure all in all though it's not that bad once you embrace the void - it's widely used because it's not terrible
|
|
#
?
Jan 8, 2020 15:52
|
|
|
Poopernickel posted:yep, it's ugly for sure hi did you just call something written in m4 template that generates bash script snippets not terrible because i think you have been down in the mines so long you forget what the sky looked like
|
|
#
?
Jan 8, 2020 18:38
|
|
|
i mean, obviously you have to accept some ugliness to solve the incredibly important problem of "check that library x is installed except please don't do it as part of compiling where it has to be looked up anyway but rather as an entirely separate and even more complex step for some reason"
|
|
#
?
Jan 8, 2020 18:43
|
|
|
autotools is a necessary evil in some cases
|
|
#
?
Jan 8, 2020 19:15
|
|
|
Cybernetic Vermin posted:i mean, obviously you have to accept some ugliness to solve the incredibly important problem of "check that library x is installed except please don't do it as part of compiling where it has to be looked up anyway but rather as an entirely separate and even more complex step for some reason" What about software that can use one of a few different libs as the backend? Or software that enables optional functionality if it has a library available at compile-time? What's your preferred way to express "when this program runs, it should get config files from $sysconfdir instead of /etc", or "for this one build on my dev machine, install everything into $home/bin instead of /opt"? What's the easiest way to make sure that your build works when the compiler tries to specify its own --sysrootdir because it's a cross-compiler? Do you like your build to run for 30 minutes and then fail to link halfway through because you didn't know you needed some library or other? you can definitely work around all of this stuff yourself manually in your own makefile, but why would you? Can you be sure you'll catch all the corner cases? Why not use a tool that's designed to deal with exactly these kinds of problems? And deals with them in a way that everybody is used to using? Autotools and cmake both fill a useful niche. CMake is a little newer, and a little easier in some cases. It's built around a bespoke macro language that isn't used anywhere else, just like autoconf. Autoconf has some better built-in features for checking if a library is available, and whether you can compile and link against it. It can even check to see if a symbol is #defined in a header, and configure the build differently if needed. CMake has a module that emulates autotools' directory-handling. Autotools needs more dependencies at source-packaging time, and fewer to configure and compile. Both let you specify standardized options and configure your build, both are super widely used, and both are terrible and have a steep learning curve. Probably a necessary evil. Poopernickel fucked around with this message at 20:16 on Jan 8, 2020 |
|
#
?
Jan 8, 2020 20:05
|
|
|
CRIP EATIN BREAD posted:thats the one reason why i was interested in that CDS server because it does builds and deployments as a dependency graphs with gates that block the flow until something triggers it. this is absolutely what i want more of and i have yet to figure out a pleasant solution, but i can usually hack something together with jenkins and by that i mean i actually use jenkins-job-builder and make sure everything is under revision control. i feel like most jenkins hate, like so many things, is driven by using it in ways that are way too bespoke and unwieldy. like, maybe you don't need a zillion plugins for something that could be accomplished with a shell script that's actually testable and maintainable
|
|
#
?
Jan 8, 2020 20:28
|
|
|
Storysmith posted:hi did you just call something written in m4 template that generates bash script snippets not terrible good point it's definitely terrible, and m4 sucks a lot I'm just saying that it offers a lot of value too, especially for distro package maintainers - and the value outweighs the hassle and general bullshit also for 99% of autoconf work, you don't need to know anything about m4 at all. Autoconf just becomes a yet another domain-specific macro language, no different than CMake except that you can use inline shell scripts too Poopernickel fucked around with this message at 20:55 on Jan 8, 2020 |
|
#
?
Jan 8, 2020 20:37
|
|
|
i once tried to compile an autogarbage thing from sources and the configuration file wasn't generated in the repo so I had to run autoconf myself and even installing the right versions of automake/autocrap was a nightmare filled with lovely errors all over the console this is the worst pile of poo poo of a build system ive ever seen and it belongs in the trash right next to make
|
|
#
?
Jan 9, 2020 00:08
|
|
|
I don't think anyone is going to bat for how great autotools is but if you need to distribute software that compiles relatively easily on a wide range of hardware & software, I'm not reallly aware of a better solution.
|
|
#
?
Jan 9, 2020 00:43
|
|
|
rotor posted:I'm not reallly aware of a better solution. Again, that doesn't mean it's good.
|
|
#
?
Jan 9, 2020 00:44
|
|
|
|
| # ? Apr 28, 2024 05:14 |
|
|
Zlodo posted:autocrap 
Poopernickel fucked around with this message at 01:23 on Jan 9, 2020 |
|
#
?
Jan 9, 2020 01:16
|
|