Weekly Edition
Return to the Announcements pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Electric Cloud Creates Open Source ''GNU Make Standard Library''
Electric Cloud has
announced the release of their GNU Make Standard
Library (GMSL) under the GPL.
"Until now, when developers wished to create a complex Makefile
they were often forced to code, from scratch, common functions, or
search the Internet for snippets of GNU Make code that could assist
them. Now, with the GMSL, GNU Make developers have a single free
collection of functions implemented using native GNU Make
functionality. The GMSL includes list and string manipulation, integer
arithmetic, associative arrays, stacks, debugging facilities and more."
(Log in to post comments)
Funny, but automake? Posted Mar 3, 2005 19:15 UTC (Thu) by danielos (guest, #6053) [Link] This will make beginner programmer more productive, but automake is better and integrate with other tools. For Debian package could have some sense, but Debian do have cdbs package for this.
Definitively good package for reading GNU Make code and maybe learn something new, but please use automake/autoconf
Funny, but automake? Posted Mar 3, 2005 20:40 UTC (Thu) by piman (subscriber, #8957) [Link] Make has many uses outside compiling C (or C-like) programs. autoconf and automake usually only complicate those situations.
Funny, but automake? Posted Mar 4, 2005 15:20 UTC (Fri) by vmole (subscriber, #111) [Link] Automake/autoconf/libtool complicate things even with C code. Supposedly designed for portability, they promote the worst habits of writing system specific code, #ifdef'd to unreadability. They're disasters. Unfortunately, they seem to be ingrained in the FOSS community. The sad part is that we knew this was the wrong approach 13 years ago. See Henry Spencer and Geoff Collyer's paper "#ifdef Considered Harmful" (only available as a PDF, so far as I can find.)
Funny, but automake? Posted Mar 4, 2005 19:02 UTC (Fri) by Ross (subscriber, #4065) [Link] The use of ifdef with the auto tools is mostly around header file inclusionor the exclusion of entire functions or compilation units.
Anywhere you have ifdef ugliness with autoconf you would be likely to have
I personally prefer the use of standardized interfaces where possible and
It certainly doesn't have to result in pre-processor spaghetti code like
Electric Cloud Creates Open Source ''GNU Make Standard Library'' Posted Mar 3, 2005 20:14 UTC (Thu) by kdart (guest, #486) [Link] scons, anyone? If you need a complete programming language for your build system, why not use a real programming language?
Electric Cloud Creates Open Source ''GNU Make Standard Library'' Posted Mar 3, 2005 22:35 UTC (Thu) by dhess (subscriber, #7827) [Link] I'll second that. scons is fantastic. I'll be using it for all future projects.
Electric Cloud Creates Open Source ''GNU Make Standard Library'' Posted Mar 3, 2005 20:21 UTC (Thu) by oak (subscriber, #2786) [Link] GAR makefile system has also a lot of rules for Make ready made:http://www.lnx-bbc.org/garchitecture.html Both Garnome (Gnome development version build system) and Konstruct (same for KDE) use it...
Could Make be any more painful....YES! Posted Mar 3, 2005 21:03 UTC (Thu) by b7j0c (subscriber, #27559) [Link] Make is one of the absolute worst tools that we still cling to. Superior alternatives are stable and free, yet still not adopted, even by new projects. Make is #1 on my list of tools to scrap with /bin/sh coming in a close second.
Could Make be any more painful....YES! Posted Mar 3, 2005 21:16 UTC (Thu) by Ross (subscriber, #4065) [Link] Alternatives? Let's restrict this to builds:
* I remember using Cake, but not very fondly.
What are the better tools you speak of?
Also, I would take /bin/sh over Perl any day. I like it better than csh too.
Could Make be any more painful....YES! Posted Mar 3, 2005 23:29 UTC (Thu) by b7j0c (subscriber, #27559) [Link] >> Alternatives?
scons,ant to a certain extent
>> Also, I would take /bin/sh over Perl any day
?? don't get me wrong, sh is fine for command line work, but even moderately compex scripts in sh are totally grody, baroque and bizarre...not to mention not providing even 1% of the featureset of a moderately modern scripting language (perl,python,ruby etc etc etc)
Could Make be any more painful....YES! Posted Mar 4, 2005 9:33 UTC (Fri) by ibukanov (subscriber, #3942) [Link] > Alternatives?
Jam, either from http://www.perforce.com/jam/jam.html or its fork from http://www.boost.org/tools/build/jam_src/index.html
Could Make be any more painful....YES! Posted Mar 4, 2005 10:23 UTC (Fri) by nix (subscriber, #2304) [Link] I've used exactly two things that were built using Jam. In both cases, doing the simplest of per-site customizations was an utter nightmare (how hard can it be to customize CFLAGS? In the end I had to *edit and rebuild Jam* to do it!) and its syntax doesn't strike me as being significantly more pleasant than make's odious syntax.
There *are* better build systems out there, but almost nobody uses them at all. make's advantage is that it provides very little but lets you build better build systems out of it with sufficient care (GNU make has gone especially far down this road). It's as suitable for writing by hand as assembler, much of the time, and as irreplaceable.
Could Make be any more painful....YES! Posted Mar 14, 2005 15:54 UTC (Mon) by rganesan (subscriber, #1182) [Link] Agreed. There are probably better build systems around than make but I am yet to see them. Any one who mentions ant hasn't really tried editing the xml by hand. I'll take make any day. Everyone complains about autoconf/automake/libtool. autoconf and libtool were great tools at a time when there were tons of proprietary Unix versions and several non-standard ways of doing the same thing. Most of these Unix variants are now dead or have adopted standard APIs and standard ways of doing things (for. e.g. HP-UX has given up on .sl library extension and shl_load() APIs in favor of .so extension and dlopen. They're probably a overkill today.However, automake makes excellent sense even today. I came across automake a few years back trying to define my own rules library. Automake turned out to be exactly what I wanted. Even though the version I used had several bugs (1.4), recent versions are actively maintained. The only complaint I have about the autotools build system is the amount of bloat they add to a project. This is mainly because of not depending on anything other than standard Bourne shell and basic make. If you divorce automake from autoconf and libtool and take advantages of GNU make and perl at run time, I think it will be a lot more usable.
Could Make be any more painful....YES! Posted Mar 4, 2005 10:08 UTC (Fri) by phd (subscriber, #952) [Link] > Alternatives?
Cons, aap, ant...
Alternatives Posted Mar 10, 2005 23:26 UTC (Thu) by Tobu (subscriber, #24111) [Link] Currently I am using an anjuta-generated template for my project. I have really little control over that, and an alternative would be very welcome.Here is what I think would be required for a flexible dependency & build system that only needs the bare minimum to be written in makefiles.
*A small declarative core, like this:
*a syntax for declaring rules
*And many many rules:
Is there anything like this at the moment?
Those who don't understand UNIX are doomed to reinvent it, poorly. Posted Mar 3, 2005 23:41 UTC (Thu) by mali (guest, #4553) [Link] ... wonder why that came to my mind.
Electric Cloud Creates Open Source ''GNU Make Standard Library'' Posted Mar 3, 2005 21:12 UTC (Thu) by jd (guest, #26381) [Link] There are many such libraries out there, plus Gnu's Automake/Autoconf series. There's also Autogen and a bunch of other aids to building makefiles. Some people even still use Imakefiles.On the one hand, the diversity of tools is good, in that it is always better to adapt a solution to a problem, rather than force a problem to fit the solution. However, that does come at a price. These tools are often clunky and interoperability sucks rocks. There are therefore two things that would be extremely useful, but aren't really there. The first would be some sort of "meta make" system that would not only provide interoperability mechanisms, but would allow the different systems to be used on their strengths. That way, you wouldn't be stuck using a solution that's optimal in one place but horrible in another. The second thing that would be useful is to modify the package management systems and tie them into the development systems. There should be no need to search for what resources your computer has, when the computer already has a perfectly good index of those resources. This requires that the indexes be searchable efficiently by resource type, which I don't believe is done but easily could be. It would also solve the problem of non-standard file paths, because it would find any installed resource, no matter where the package manager put it. Currently, those systems that do perform a search will only find the first instance of a known name on a known path. So, if you're using a Sun system, you may find /usr/bin/cc or /usr/usb/cc, but never both. Which means if one is broken, you're SOL. That's not a clean design. If you're using Fedora's GCC4 RPMs, autoconf may have problems, because the filename is going to be "wrong". It may not see the compiler, even though you have a perfectly good one installed. On the other hand, if you indexed by something like trove categories and had a search system look there first, it would see both the compilers in the first example and therefore be able to try both. If one doesn't work, that's no big deal. In the second case, it would find gcc4, even though it is not a "normal" name for a C compiler, because the package manager would label it as such. The "real" ideal would be to combine both of the above into the filesystem, such that one could identify the package, purpose and nature of a file by means of a simple adaptation of tools like "file". Thus, you would not only be able to ask the system for all installed C compilers, but you'd also be able to ask a file if it was a C compiler. This wouldn't require signficantly more physical storage. What it would require is that package management be done in a database filesystem of some sort, with symlinks in both directions associating physical files with a description of the capabilities of that file. This would also allow you to do things like associate MIME types to applications. The program would be attached to one or more MIME types, each MIME type woud be associated with one or more applications, and those applications would be associated with one or more functions. It would then be possible for a user to request that a given function be performed on a file, and for the system to identify what would be able to do that. In the case of programming, there are many lexical analyzers out there, but there might only be one that is installed that will work on the lexical file in question. You don't then have to try each in turn to find out.
Electric Cloud Creates Open Source ''GNU Make Standard Library'' Posted Mar 4, 2005 1:11 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Sorry, but one association of file (type) with an application won't cut it. Just as you complained earlier that it isn't easy to find all C compilers, it isn't easy to find all PDF readers, let alone the one a particular user prefers (for whatever reason, they might even be developing one of their own). And so on for each type. And fix dependencies if/when the default one is dumped for a new one. Etc.
Electric Cloud Creates Open Source ''GNU Make Standard Library'' Posted Mar 4, 2005 17:23 UTC (Fri) by iabervon (subscriber, #722) [Link] It seems to me that people largely misunderstand the function of make. It is not, itself, a build system, but rather a language for writing build systems, with an optimized syntax and build-in library. Most of the proposed alternatives are not languages; they're build systems. That is, scons is not in any way an alternative to make; Python is an alternative to make, and scons is a build system written in Python.
This is complicated somewhat by the fact that people tend to write one-off build systems in make or use further tools to generate build systems for make. Very few projects actually provide simply a make-based build system, and few have a make-based build system separate from the information used to build the particular project. I've actually written 5 build systems with make at this point, and I find it incredibly convenient to be able to have a build system with some special rules (e.g., "program the fuse bits on the microcontroller") already prepared when I start a new project. It's also good to have the build system separate from the project information so that improvements to the build system can apply to everything. (The 5 are C in a big tree, Java, C for microcontrollers, Java at a previous job, and C with one library package and other packages for work.)
|
|||||||||||