[FoRK] Raise your hand if you rate minimum LOC as an important metric

Stephen D. Williams sdw at lig.net
Mon Jan 14 10:01:14 PST 2013


More concise almost always wins or should win.
There's no reason that you couldn't get roughly the same conciseness with C++ or Java or Javascript, given a roughly equivalent library.

It is the design that is wrong if it takes 100x LOC to do the equivalent thing.

For actually building compiled code, CMake is pretty much winning it seems.  It could probably be used as an installer, although the 
purpose built solutions for that probably have some key advantages.  In any case, you might want to consider CMake's metamake design 
with toolchain and package modules.  It supports very concise, very portable expression of a wide range of build capabilities.  It 
directly supports finding things on a local system, all variances in local build environments (.a/.lib, etc.) with toolchain files, 
including cross-compiling.  And it is completely customizable.  I've built large Java projects with it. The only limitation is 
directly handling of building code generated during the build, but I solved that well with a short-circuited two pass build that 
still maintained full dependency tracking.

I much prefer CMake to Ant, gmake (although Google's done well with that for Android), etc.

Stephen

On 1/11/13 10:19 PM, Joseph S. Barrera III wrote:
> I'm currently trying to replace a (piece of build software) that requires > 100 KLOC C++/rpm spec files/etc with something that 
> uses <= 1 KLOC python.
>
> I'm getting intense opposition from (person*) because my solution does not use "existing best practices" but is instead home-grown.
>
> But the so-called "existing best practices" include a 40 KLOC port of apt (debian tool) to RPM/RHEL (?!) which has not been 
> supported for many years.
>
> It also includes many lines of rpm *.spec files. The previous developer likes to claim that since he is using RPM, he gets 
> relocatability for free. But he doesn't use %post (which would be invoked at install, after build), and everything he does at 
> build-time, I already do as well.
>
> My build system has lines like (and this includes test of functionality, hence the occasional second parameter which indicates a 
> non-obvious python import):
>
>     env.build_python('virtualenv')
>     env.build_python('kerberos')
>     env.build_python('paramiko')
>     env.build_python('poster')
>     env.build_python('urllib2_kerberos', 'urllib2')
>     env.build_python('pyfits')
>
>     # (these are the complicated cases)
>
>     b = package(env, 'tables')
>     if not b.installed():
>         b.extract()
>         hdf5_dir = b.get_absolute_install_dir('hdf5')
>         b.setup_build('--hdf5=%s' % hdf5_dir)
>         b.setup_install('--hdf5=%s' % hdf5_dir)
>         b.check_import()
>
>     b = package(env, 'sip')
>     if not b.installed():
>         b.extract()
>         b.configure_py('-e %s/include/%s' % (b.absolute_install_dir, env.python))
>         b.make()
>         b.make_install()
>         b.check_import()
>
> The typical spec file in the old system is ~100 lines. Many of my build lines are single-liners and the rest are ~ 10 lines.
>
> The RPM proponent is very vocal and has great political advantage.
>
> Any advice or help?
>
> Thanks,
>
> - Joe
>
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork


-- 
Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer



More information about the FoRK mailing list